11 ms·

I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from us

I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from using DOM to canvas. I never noticed a huge difference between the two methods but I imagine using canvas gave them a lot more flexibility in addition to being more performant.

disease 5y ago
Here's an article that talks about the switch to canvas for VS Code. The "5 to 45" times faster part really sticks out to me. Kind of surprised it took Google this long to do this with Docs. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
- shadowgovt 5y ago
  > Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.
  - woah 5y ago
    Look at the Google docs generated html markup some time. It’s not making nice neat <p>’s and <h1>’s.
    - kaliszad 5y ago
      Yes, at OrgPad, we are writing our own rich text editor and if you want to use the DOM approach, you don't have much choice than to do it like this. You can see the WIP demo here (in Czech but it is quite visual): https://www.youtube.com/watch?v=SkFJ1zcRjQY https://www.youtube.com/watch?v=SkFJ1zcRjQY It is also written in ClojureScript. Some of the reasoning is here (in English, but 3 hours long): https://www.youtube.com/watch?v=4UoIfeb31UU https://www.youtube.com/watch?v=4UoIfeb31UU
    - m0dest 5y ago
      How? I thought they blocked access to the native underlying document format. Or do you mean the HTML export?
      - Gaelan 5y ago
        I assume your parent means the result of clicking inspect element in the (pre-canvas) editor.
- xxpor 5y ago
  I personally didn't even bother checking out VS code because it was based on electron, and so I figured the performance just wouldn't be there because it's doing all of this awkward web stuff while trying to be an IDE. I was completely wrong though. Using it, it really doesn't feel like a web app at all. It's really shocking and impressive. It feels like a text editor. Perhaps I should learn more about what they're doing.
  - jackcviers3 5y ago
    The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner. This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side. AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. With enough extensions to make it usable, vscode easily eats GB of memory. I like lsp. But I don't need vscode to do the rendering.
    - xxpor 5y ago
      I just in the past month upgraded my main work laptop from 16 GB from 40 GB (8 GB soldered + 32 GB SODIMM). So your point is granted, but on the other hand, DDR4 prices have collapsed ~50% from 2018 (I couldn't believe it either, given all of the other semiconductor issues).
      - murukesh_s 5y ago
        nice, but you are lucky to have laptop that have extra RAM slot. not everyone can do that.
        mdoms 5y ago
        Luck has nothing to do with it, the Macbook Pro users know what they're getting into.
        xxpor 5y ago
DaiPlusPlus 5y ago
> I imagine using canvas gave them a lot more flexibility in addition to being more performant. I'm perplexed because I don't expect canvas rendering to be faster - or necessarily more flexible - because the web is document-first: HTML and CSS were/are all built-around describing and styling textual content, and computer program source code files are invariably all textual content files. So while browsers all have heavily-optimized fast-paths written in native code for rendering the DOM to the screen with the full flexibility of all of CSS's styling features - so applications switching to canvas rendering will first have to contend with needing to reimplement at least the subset of CSS that they're using for their editor - and it has to run as JavaScript (or WASM?) - and I just don't understand how that could possibly be faster than letting the DOM do its thing. I appreciate that DOM+CSS rendering is not designed-around monospaced text editing or with specific support for typical text-editor and IDE features which do indeed throw a wrench into the works[1], but I think a much better approach would be to carve-out the cases where the current DOM and rendering model is insufficient or inappropriate for those specific applications' purposes and find a way to solve those problems without resorting to canvas rendering. That said, is this change because Google wants to use Flutter for a single codebase for Google Docs that would work across iOS, Android, and the web? Flutter does have a HTML+DOM+CSS rendering mode, but it's horrible (literally thousands of empty <div> elements in their hello-world example...) [1] e.g. a HTML/DOM document is strictly an unidirectional acyclic tree structure, and CSS selectors are also strictly forwards-only (e.g. you cannot have a HTML element that spans other elements, you cannot isolate individual text characters, you cannot select a descendant element to style based on its subsequent siblings, or ancestor's subsequent siblings), and how the render-state of a document is also strictly derived from the DOM and so does not allow for any feedback loops unless you start to use scripts, which means you can't select elements to style based on their computed styles (unlike, for example, WPF+XAML, where you can bind any property to another property - something I think XAML implements horribly...), and I appreciate this makes certain kinds of UI/UX work difficult (if not impossible in some cases), but in the use-case of an editor I just don't see these as being show-stopper issues.
- dkarras 5y ago
  >I'm perplexed because I don't expect canvas rendering to be faster ...yet it is. Really. Even though DOM paths are heavily optimized, they are extremely flexible, and that flexibility creates a wall in possible performance optimizations. In a context like word processor, precision is more important than your regular website (and across browsers!) so you end up implementing little hacks everywhere, pushing half a pixel here and another 1.5 pixels there. A purpose built engine that writes directly to the framebuffer of a canvas without dealing with legacy cruft has the potential to be a lot faster - if you know what you are doing. Google has no shortage of devs who know what they are doing so here we are.
kaliszad 5y ago
I like the hacking mindset to make something work even if the odds are against it but the better approach would be to fix the DOM APIs and to do the necessary performance work instead of basically throwing all the responsibility on some library and the web developer.
raydev 5y ago
I haven't noticed the change either, scrolling is somewhere less than 60fps on new Mac hardware. It's the only thing about VS Code I would change: have it use native APIs for text rendering so we can get the same framerate as native apps.

disease 5y ago

Here's an article that talks about the switch to canvas for VS Code. The "5 to 45" times faster part really sticks out to me. Kind of surprised it took Google this long to do this with Docs. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

shadowgovt 5y ago
> Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.
- woah 5y ago
  Look at the Google docs generated html markup some time. It’s not making nice neat <p>’s and <h1>’s.
  - kaliszad 5y ago
    Yes, at OrgPad, we are writing our own rich text editor and if you want to use the DOM approach, you don't have much choice than to do it like this. You can see the WIP demo here (in Czech but it is quite visual): https://www.youtube.com/watch?v=SkFJ1zcRjQY https://www.youtube.com/watch?v=SkFJ1zcRjQY It is also written in ClojureScript. Some of the reasoning is here (in English, but 3 hours long): https://www.youtube.com/watch?v=4UoIfeb31UU https://www.youtube.com/watch?v=4UoIfeb31UU
  - m0dest 5y ago
    How? I thought they blocked access to the native underlying document format. Or do you mean the HTML export?
    - Gaelan 5y ago
      I assume your parent means the result of clicking inspect element in the (pre-canvas) editor.
xxpor 5y ago
I personally didn't even bother checking out VS code because it was based on electron, and so I figured the performance just wouldn't be there because it's doing all of this awkward web stuff while trying to be an IDE. I was completely wrong though. Using it, it really doesn't feel like a web app at all. It's really shocking and impressive. It feels like a text editor. Perhaps I should learn more about what they're doing.
- jackcviers3 5y ago
  The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner. This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side. AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. With enough extensions to make it usable, vscode easily eats GB of memory. I like lsp. But I don't need vscode to do the rendering.
  - xxpor 5y ago
    I just in the past month upgraded my main work laptop from 16 GB from 40 GB (8 GB soldered + 32 GB SODIMM). So your point is granted, but on the other hand, DDR4 prices have collapsed ~50% from 2018 (I couldn't believe it either, given all of the other semiconductor issues).
    - murukesh_s 5y ago
      nice, but you are lucky to have laptop that have extra RAM slot. not everyone can do that.
      - mdoms 5y ago
        Luck has nothing to do with it, the Macbook Pro users know what they're getting into.
      - xxpor 5y ago

DaiPlusPlus 5y ago

> I imagine using canvas gave them a lot more flexibility in addition to being more performant. I'm perplexed because I don't expect canvas rendering to be faster - or necessarily more flexible - because the web is document-first: HTML and CSS were/are all built-around describing and styling textual content, and computer program source code files are invariably all textual content files. So while browsers all have heavily-optimized fast-paths written in native code for rendering the DOM to the screen with the full flexibility of all of CSS's styling features - so applications switching to canvas rendering will first have to contend with needing to reimplement at least the subset of CSS that they're using for their editor - and it has to run as JavaScript (or WASM?) - and I just don't understand how that could possibly be faster than letting the DOM do its thing. I appreciate that DOM+CSS rendering is not designed-around monospaced text editing or with specific support for typical text-editor and IDE features which do indeed throw a wrench into the works[1], but I think a much better approach would be to carve-out the cases where the current DOM and rendering model is insufficient or inappropriate for those specific applications' purposes and find a way to solve those problems without resorting to canvas rendering. That said, is this change because Google wants to use Flutter for a single codebase for Google Docs that would work across iOS, Android, and the web? Flutter does have a HTML+DOM+CSS rendering mode, but it's horrible (literally thousands of empty <div> elements in their hello-world example...) [1] e.g. a HTML/DOM document is strictly an unidirectional acyclic tree structure, and CSS selectors are also strictly forwards-only (e.g. you cannot have a HTML element that spans other elements, you cannot isolate individual text characters, you cannot select a descendant element to style based on its subsequent siblings, or ancestor's subsequent siblings), and how the render-state of a document is also strictly derived from the DOM and so does not allow for any feedback loops unless you start to use scripts, which means you can't select elements to style based on their computed styles (unlike, for example, WPF+XAML, where you can bind any property to another property - something I think XAML implements horribly...), and I appreciate this makes certain kinds of UI/UX work difficult (if not impossible in some cases), but in the use-case of an editor I just don't see these as being show-stopper issues.

dkarras 5y ago
>I'm perplexed because I don't expect canvas rendering to be faster ...yet it is. Really. Even though DOM paths are heavily optimized, they are extremely flexible, and that flexibility creates a wall in possible performance optimizations. In a context like word processor, precision is more important than your regular website (and across browsers!) so you end up implementing little hacks everywhere, pushing half a pixel here and another 1.5 pixels there. A purpose built engine that writes directly to the framebuffer of a canvas without dealing with legacy cruft has the potential to be a lot faster - if you know what you are doing. Google has no shortage of devs who know what they are doing so here we are.

kaliszad 5y ago

I like the hacking mindset to make something work even if the odds are against it but the better approach would be to fix the DOM APIs and to do the necessary performance work instead of basically throwing all the responsibility on some library and the web developer.

raydev 5y ago

I haven't noticed the change either, scrolling is somewhere less than 60fps on new Mac hardware. It's the only thing about VS Code I would change: have it use native APIs for text rendering so we can get the same framerate as native apps.