Earlier quoted context omitted.
Padora box was already open the day, WebAssembly and WebGL came into the browser.
You can render in canvas with JavaScript only, no WebAssembly nor WebGL is needed.
Naturally, the point being made was about Flash.
Google Docs will now use canvas based rendering
371–380 of 953 posts
Re: Google Docs will now use canvas based rendering
#372Earlier quoted context omitted.
> The dom is really, really fast, no, it is barely tolerable. Web apps in 2021 have trouble reaching the UI performance (latency) of early 2000 desktop software.
quite a blanket statement both for web and desktop apps... some are fast some are slow on both platforms, no?
It’s a blanket statement because the time to render a standards based user interface is very small. Once we bring in the latency of the internet, (or on the desktop side, database or any other networked resource) all bets are off.
It makes sense for Google to make this change. Why should I care anyway? Its not like anybody has cared about open document formats in this space anyway. This never was and never will be an open platform.
I find it frustrating because this is just another nail in the coffin for open documents.
Re: Google Docs will now use canvas based rendering
#373I think this is a pretty logical evolution.
In my opinion they should wait a bit and build a solid C++/WebGPU on WebAssembly renderer to skip a few steps and avoid doing the same work a few years down the line.
The web was designed to display document, not to host application, it was stretched very far but is also extremely complex and kind of slow.
Re: Google Docs will now use canvas based rendering
#374Ever 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…
>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
As opposed to a world where huge, unintelligible minified JavaScript blobs are sent to the browser?
Re: Google Docs will now use canvas based rendering
#375Earlier quoted context omitted.
A dystopia. You can't control-F in the page. Can't copy and paste a word you don't know into a translator or dictionary. Can't share text unofficially - like copy a sentence into a email, etc.
Also, you know, accessibility. This could be a real serious problem for people with disabilities.
This is 100% the reason why I decided not to use Flutter back when I was shopping.
It probably would have reduced my developer effort considerably compared to basically every other option that made it to my short list, but I can't in good conscience build something that isn't accessible.
Re: Google Docs will now use canvas based rendering
#376Would love to hear a Googler justify this. It's just closing down the web. No more view source for the curious kids. Shame on you.
Re: Google Docs will now use canvas based rendering
#377Ever 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…
Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. Some of them work well despite this, but, it’s a horrible set of code to maintain and very, very hard to make a good user experience. One of the very hardest things to do well in the browser, actually.…
Furthermore, actually implementing your own text renderer and input engine in WASM is a different horrible nightmare, because you've now forfitted any chance of supporting IMEs (e.g. touch keyboards, pinyin/romaji/kanji input, iPadOS Scribble), you need to implement your own text selection inputs, your text won't show up in the accessibility tree, and you can't copy-paste without additional, browser-specific tweaks. The only reason to actually do this is if you can't use HTML.
Source: I am a Ruffle developer and have had to do exactly this to support text input in old Flash games.
Re: Google Docs will now use canvas based rendering
#378Ever 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…
Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. Some of them work well despite this, but, it’s a horrible set of code to maintain and very, very hard to make a good user experience. One of the very hardest things to do well in the browser, actually.…
A million times this - having worked in this space, nobody wants to do this. I understand the cynicism, but the affordances provided by the browser for things like accessibility are very painful to give up. This isn't some dark pattern attempt to cut out whatever "openness" remains on the web, or to convert the browser into a display-streaming client for some sinister DRM reason.
In my past job, we rewrote our spreadsheet rendering to use canvas and gained massively in simplicity and maintainability. And there was no obfuscation angle to it - we even shipped source maps! Handling accessibility and text input was hard (we ended up adopting a hybrid-DOM model where some things like input fields were still native ones, or shadowed by native ones), and even then it was still easier than dealing with browser rendering.
This is simply a reasonable way to work around the DOM being trash. The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.
Re: Google Docs will now use canvas based rendering
#379Earlier quoted context omitted.
No, it can't be done in HTML+CSS in a performant way.
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 tric…
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
Re: Google Docs will now use canvas based rendering
#380Earlier quoted context omitted.
This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.
It`s not slow on an old intel i3 laptop and on a motorola one phone. I keep seeing these comments about flutter web with different examples, they are never slow on my old devices. Also you can make the text selectable if you want to.
there is an option for flutter to compile for both canvaskit and html - and then on mobile might select the latter (for reasons being smaller) - it might be that (not sure).
I have two stupid flutter apps that are canvas only - https://malkia.github.io/game_of_life/ and https://malkia.github.io/tictactoe (but haven't rebuilt them with latest & greatest)