4 ms·

The part I don’t understand is how in the world is a renderer written in JavaScript better performing than their own Chrome c++ code? With Edge being a Chrome c

by harikb 5y ago

The part I don’t understand is how in the world is a renderer written in JavaScript better performing than their own Chrome c++ code? With Edge being a Chrome clone and Safari being also performant browser, what are they worried about?

recursive 5y ago
Their own renderer has to support all of HTML and CSS. Slapping some rectangles on a raster surface has a lot less to worry about.
- zozbot234 5y ago
  "Slapping some rectangles on a raster surface" can also be done in HTML/CSS, with the right options (set 'overflow' content to be clipped with no reflow).
  - dmitriid 5y ago
    No, it can't be done in HTML+CSS in a performant way.
    - strogonoff 5y ago
      VS Code feels performant enough, with its complex functionality IMO exceeding Google Docs, and yet I don't think it is using canvas. I believe it comes down to strategic design that avoids unnecessary layout and reflow events in the UI. That said, the UI of VS Code (the desktop app) only needs to run in Chromium. And generally Google Docs could be a different enough beast that it can’t take advantage of the same tricks—hard to say from the outside.
      - d-yakovlev 5y ago
        some of VS Code has been canvas-based since 2017 - https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
        strogonoff 5y ago
        I stand corrected, seems like they’re using canvas for at least the integrated terminal and maybe (?) the editor. Makes all the more sense for Google Docs to follow suit. I’m not against apps moving entirely to canvas by the way, as long as the regular non-webapp sites don’t start doing this just because they can.
        Tyriar 5y ago
        The editor is all DOM based apart from the minimap. More pixels could definitely be pushed faster by re-writing it in canvas but it would be quite the undertaking when you consider accessibility, backwards compatibility, monaco extensibility, etc. with the end result just being a improved scrolling experience.
      - mvolfik 5y ago
        but VS code still only has to support monospaced code + some popups and sidebars, not mix-and-match of font and all its variants in all complex layouts, line heights, paragraph spaces, column layouts, images including float etc etc
      - dmitriid 5y ago
        > VS Code feels performant enough, with its complex functionality VS Code has an entire dedicated team that only works on VS Code. They can spend resources on trying any trick in the book to make something performant. Whenever actual performance is required, well, they ditch DOM and go for canvas: https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend... And while sufficiently complex, it actually displays significantly less complex information than required by a regular document that will have any number of fonts, layouts, inline images and tables, references to other documents, etc. > I believe it comes down to strategic design that avoids unnecessary layout and reflow events in the UI. Yup. And it's nearly impossible to do any amount of "strategic design" because if you as much as glance at a document, it will repaint and reflow: https://csstriggers.com https://csstriggers.com
- danShumway 5y ago
  Well... sort of. For specific apps, or parts of apps, yes. Doing less is how you make things faster, highly agreed. And sometimes canvas allows you to do that, and then your app is much faster. The problem is that in many cases, moving to canvas eventually turns into having a UI framework that renders to canvas, which turns into a layer of abstractions that handle keyboard and mouse events for you, including stuff like hover, which means suddenly you're tracking element position on your raster surface and thinking about z-indexes and event bubbling to parent elements... I think this is part of the reason why individual apps that start using canvas and that can genuinely cut down on complexity by doing so tend to be able to get real speed improvements, but app frameworks like Flutter tend to perform so poorly. Eventually your cross-platform GUI toolkit like Flutter ends up being just another browser engine written in WASM. And in that scenario your approach becomes strict downside. One good example: the browser doesn't expose an accessibility engine other than the DOM. So what I see apps end up eventually doing is either writing their own accessibility engine that doesn't work with programs like JAWS, or rendering out to a hidden DOM. For something like a game, you can get away that, maybe you don't even provide an accessibility layer at all. For a web component or a chart, a lot of your rendering might be unrelated to accessibility at all. But you get away with those kind of shortcuts because it's a targeted, specific use. For a big UI toolkit, it's harder to do that, and then surprise, suddenly you have all the overhead of updating a DOM tree and the overhead of updating a canvas. When people talk about getting raw access to the graphics layer, I think it's important to understand there's a difference between apps that are genuinely reducing complexity vs the theoretical canvas-backed "universal web framework" that people sometimes talk about as just around the corner.
  - andrewingram 5y ago
    Are you sure you meant Figma? It's an image editor, not a framework.
    - danShumway 5y ago
      Eh, bleh, you're completely right, I meant Flutter. Good catch. Figma is not only not a framework, it's also not completely canvas based, or at least wasn't last time I checked.
moshmosh 5y ago
Judging from Google Docs' performance, they're already not really using the browser for much.
altcognito 5y ago
They will use WASM, and it will become big and clunky.
jcelerier 5y ago
> With Edge being a Chrome clone yes > and Safari being also yes > performant browser, no Browser UI is so slow when compared to non-browser UI, it's infuriating.
shadowgovt 5y ago
JavaScript is actually quite fast these days, especially if one has a compiler in the flow to narrow it to the set of operations that are known to be high-performance. And Google would be paying a lot of that cost anyway if the DOM is the render target, because what they gain in the render algorithm being precompiled assembly they lose in the JavaScript layer pushing the wrong abstraction around to trigger all that C++ code.
- criddell 5y ago
  > JavaScript is actually quite fast these days Do you think a browser written entirely in JavaScript would be competitive with Chrome written in C++?
  - shadowgovt 5y ago
    Do I have Google's engineers to develop it and full control over the implementation of the JS engine? Am I allowed to compile the JavaScript to assembly? Because if yes to all of these, then in the abstract, as a thought experiment, I can create an implementation in the JavaScript language with machine code that is byte-for-byte compatible with Chrome written in C++. Step one is write a C++ compiler in JavaScript... ;) ... but more importantly, I don't know how the question is relevant to the question of whether a JavaScript implementation of render commands into a canvas might be faster than a JavaScript implementation of layout declarations that have to play a bunch of games to get desired results from a C++ renderer. The gains from C++ render performance start to get lost if the renderer is making a bunch of wrong guesses about what should be rendered and when.
  - tshaddox 5y ago
    That's kinda a weird question, since it would obviously depend on what is executing the JavaScript for the browser written entirely in JavaScript. Chrome doesn't ship C++ code to your machine, they compile the C++ to native code for your particular hardware and operating system (presumably with a great many differences and performance tweaks between each compilation target).

by harikb 5y ago

recursive 5y ago

Their own renderer has to support all of HTML and CSS. Slapping some rectangles on a raster surface has a lot less to worry about.

zozbot234 5y ago
"Slapping some rectangles on a raster surface" can also be done in HTML/CSS, with the right options (set 'overflow' content to be clipped with no reflow).
- dmitriid 5y ago
  No, it can't be done in HTML+CSS in a performant way.
  - strogonoff 5y ago
    VS Code feels performant enough, with its complex functionality IMO exceeding Google Docs, and yet I don't think it is using canvas. I believe it comes down to strategic design that avoids unnecessary layout and reflow events in the UI. That said, the UI of VS Code (the desktop app) only needs to run in Chromium. And generally Google Docs could be a different enough beast that it can’t take advantage of the same tricks—hard to say from the outside.
    - d-yakovlev 5y ago
      some of VS Code has been canvas-based since 2017 - https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
      - strogonoff 5y ago
        I stand corrected, seems like they’re using canvas for at least the integrated terminal and maybe (?) the editor. Makes all the more sense for Google Docs to follow suit. I’m not against apps moving entirely to canvas by the way, as long as the regular non-webapp sites don’t start doing this just because they can.
        Tyriar 5y ago
        The editor is all DOM based apart from the minimap. More pixels could definitely be pushed faster by re-writing it in canvas but it would be quite the undertaking when you consider accessibility, backwards compatibility, monaco extensibility, etc. with the end result just being a improved scrolling experience.
    - mvolfik 5y ago
      but VS code still only has to support monospaced code + some popups and sidebars, not mix-and-match of font and all its variants in all complex layouts, line heights, paragraph spaces, column layouts, images including float etc etc
    - dmitriid 5y ago
      > VS Code feels performant enough, with its complex functionality VS Code has an entire dedicated team that only works on VS Code. They can spend resources on trying any trick in the book to make something performant. Whenever actual performance is required, well, they ditch DOM and go for canvas: https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend... And while sufficiently complex, it actually displays significantly less complex information than required by a regular document that will have any number of fonts, layouts, inline images and tables, references to other documents, etc. > I believe it comes down to strategic design that avoids unnecessary layout and reflow events in the UI. Yup. And it's nearly impossible to do any amount of "strategic design" because if you as much as glance at a document, it will repaint and reflow: https://csstriggers.com https://csstriggers.com
danShumway 5y ago
Well... sort of. For specific apps, or parts of apps, yes. Doing less is how you make things faster, highly agreed. And sometimes canvas allows you to do that, and then your app is much faster. The problem is that in many cases, moving to canvas eventually turns into having a UI framework that renders to canvas, which turns into a layer of abstractions that handle keyboard and mouse events for you, including stuff like hover, which means suddenly you're tracking element position on your raster surface and thinking about z-indexes and event bubbling to parent elements... I think this is part of the reason why individual apps that start using canvas and that can genuinely cut down on complexity by doing so tend to be able to get real speed improvements, but app frameworks like Flutter tend to perform so poorly. Eventually your cross-platform GUI toolkit like Flutter ends up being just another browser engine written in WASM. And in that scenario your approach becomes strict downside. One good example: the browser doesn't expose an accessibility engine other than the DOM. So what I see apps end up eventually doing is either writing their own accessibility engine that doesn't work with programs like JAWS, or rendering out to a hidden DOM. For something like a game, you can get away that, maybe you don't even provide an accessibility layer at all. For a web component or a chart, a lot of your rendering might be unrelated to accessibility at all. But you get away with those kind of shortcuts because it's a targeted, specific use. For a big UI toolkit, it's harder to do that, and then surprise, suddenly you have all the overhead of updating a DOM tree and the overhead of updating a canvas. When people talk about getting raw access to the graphics layer, I think it's important to understand there's a difference between apps that are genuinely reducing complexity vs the theoretical canvas-backed "universal web framework" that people sometimes talk about as just around the corner.
- andrewingram 5y ago
  Are you sure you meant Figma? It's an image editor, not a framework.
  - danShumway 5y ago
    Eh, bleh, you're completely right, I meant Flutter. Good catch. Figma is not only not a framework, it's also not completely canvas based, or at least wasn't last time I checked.

moshmosh 5y ago

Judging from Google Docs' performance, they're already not really using the browser for much.

altcognito 5y ago

They will use WASM, and it will become big and clunky.

jcelerier 5y ago

> With Edge being a Chrome clone yes > and Safari being also yes > performant browser, no Browser UI is so slow when compared to non-browser UI, it's infuriating.

shadowgovt 5y ago

JavaScript is actually quite fast these days, especially if one has a compiler in the flow to narrow it to the set of operations that are known to be high-performance. And Google would be paying a lot of that cost anyway if the DOM is the render target, because what they gain in the render algorithm being precompiled assembly they lose in the JavaScript layer pushing the wrong abstraction around to trigger all that C++ code.

criddell 5y ago
> JavaScript is actually quite fast these days Do you think a browser written entirely in JavaScript would be competitive with Chrome written in C++?
- shadowgovt 5y ago
  Do I have Google's engineers to develop it and full control over the implementation of the JS engine? Am I allowed to compile the JavaScript to assembly? Because if yes to all of these, then in the abstract, as a thought experiment, I can create an implementation in the JavaScript language with machine code that is byte-for-byte compatible with Chrome written in C++. Step one is write a C++ compiler in JavaScript... ;) ... but more importantly, I don't know how the question is relevant to the question of whether a JavaScript implementation of render commands into a canvas might be faster than a JavaScript implementation of layout declarations that have to play a bunch of games to get desired results from a C++ renderer. The gains from C++ render performance start to get lost if the renderer is making a bunch of wrong guesses about what should be rendered and when.
- tshaddox 5y ago
  That's kinda a weird question, since it would obviously depend on what is executing the JavaScript for the browser written entirely in JavaScript. Chrome doesn't ship C++ code to your machine, they compile the C++ to native code for your particular hardware and operating system (presumably with a great many differences and performance tweaks between each compilation target).