Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…
It's a bad thing in terms of openness but a good thing in terms of performance and making web applications more like real desktop applications. A lot of DOM work is a nightmare, so I sort of welcome to the Canvas based approach.
Google Docs will now use canvas based rendering
141–150 of 953 posts
Re: Google Docs will now use canvas based rendering
#142Earlier quoted context omitted.
I want to say that Flutter would be a good candidate, but I don't think it's ready for this. Or is it?
Isn't Flutter intended exactly for this use case? If Google Docs won't use Flutter then I'd say Flutter has failed badly.
It remains to be seen how much long lasting love it is having across the Googleplex.
Re: Google Docs will now use canvas based rendering
#143I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. > If you are building your own integrations with Google Docs, we recommend using Google Work…
The DOM gives a developer very little control over when something should be repainted (or how repainting occurs) relative to the compositing options available when controlling one's own canvas. Moving the rendering engine to canvas allows the docs team more control over the optimizations of layout and rendering they can do (especially cross-platform; there are a hundred hundred mutually-incompatible bugs and quirks in Firefox, Chrome, IE, etc.'s layout and content rendering algorithms that make cross-platform high-performance very hard to guarantee at the DOM layer of abstraction).
Re: Google Docs will now use canvas based rendering
#144Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable…
Re: Google Docs will now use canvas based rendering
#145Earlier quoted context omitted.
And it puts the entire structure behind a giant blackbox. Yucky. Technically, sure, but the reality is that very few people are interacting directly with the HTML content of a Google Doc. What it does behind the scenes is really only relevant to the developers working on the app.
Well it also breaks all context menu functionality. No more right click -> copy text unless the website specifically implements it. Any custom context menu you use is now useless. Personally I always use 'Right click -> Search..'
Re: Google Docs will now use canvas based rendering
#146It's like going back in time with Flash Player, There were many WYSIWYG flash based editors around 2010. The problem was it required a browser plugin but it did work much better then HTML4 at that time. For canvas rendering no plugin is needed. Even there was a feature to export SWF file to canvas. There are some issues like accessibility, browser features like search or text highlighting, lazy loading etc. What HTML…
Padora box was already open the day, WebAssembly and WebGL came into the browser.
Re: Google Docs will now use canvas based rendering
#147Accessibility notes: “ we generate a second DOM tree parallel to the DOM tree used as the RenderObject tree and translate the flags, actions, labels, and other semantic properties into ARIA.” https://medium.com/flutter/going-deeper-with-flutters-web-su...
https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
I don't see a secondary ARIA DOM. Wave tool sees no semantic content.
Can someone from Google docs team explain what A11y features will be enabled at launch?
https://wave.webaim.org/report#/https://docs.google.com/docu...
Re: Google Docs will now use canvas based rendering
#148How would they implement things like copy-to-clipboard then?
Re: Google Docs will now use canvas based rendering
#149Earlier quoted context omitted.
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.
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-rend...
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.
Re: Google Docs will now use canvas based rendering
#150Earlier quoted context omitted.
It depends on what you do with it. HN is extremely fast.
(Un)folding a 100+ comment subtree is kind of slow, don't you think?