Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

231–240 of 953 posts

Re: Google Docs will now use canvas based rendering

#232

This reminds me a lot of those websites that used to be implemented in Flash. It's just one giant opaque blob that gets downloaded and can do whatever it wants. When this stuff inevitably starts being used by every news and shopping website I wonder how search engines will be able to index it.

Does not make much sense. If search engines can't index it, no news website will do it.

Re: Google Docs will now use canvas based rendering

#233
post #88

Earlier 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.

> 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 h…

>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.

Re: Google Docs will now use canvas based rendering

#234
post #185
post #99

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…

I've watched a weird mix of "I don't like javascript" that usually actually translates to "I don't like what some people do with javascript." along side some cheer leading for webassembly... Now those obviously aren't entirely connected arguments, but whatever "I don't like what some people do with javascript" is supposed to mean, it has nothing to do with javascript. It's just what people do with it. Here we go now,…

Not like you know what that obfuscated minimized javascript was doing anyway.

Re: Google Docs will now use canvas based rendering

#235

Earlier quoted context omitted.

I suspect that accuracy of rendering and consistency across platforms is the bigger concern here. There are enough differences between how different browsers and operating systems render text via the DOM, to make it very hard to get consistent results between then all. By using canvas they can get very close to pixel perfect consistency. (Especially if they bring their own FreeType library or similar along.)

You can already get nearly pixel-perfect consistency by rendering each character as a separate dom element at specific X-Y coordinates. Then the browser isn't responsible for line wrapping or anything. It has the benefit you can still use the browser for GPU acceleration and calculation of damage rectangles. I'd also question how important identical cross-device rendering is in todays world of vastly different screen…

> You can already get nearly pixel-perfect consistency by rendering each character as a separate dom element at specific X-Y coordinates.

You could do that for every character, but the size of the DOM and updating it will kill your performance. You're better off just drawing the characters yourself into a canvas then.

Re: Google Docs will now use canvas based rendering

#236
post #99

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…

User preference and configurability of hyperTEXT display has been totally thrown under the bus, increasingly throughout the web's existence. I remember when it was straightforward to have your own text color and font preference, and web sites didn't try to override them. You could even configure a brick wall GIF background for sites if you wanted to. Now, these preferences are buried and easy for a developer to ignore using CSS and JavaScript. And as you say, it'll get even worse. The user agent (who, by the way, you're writing your web site for) now has very little say in how a web page is rendered.

Unpopular opinion on HN full of web devs, but I don't want my browser to be a "canvas" for some developer. I don't want it to be a "stable ABI" for some opaque binary app. I already have a platform for binary applications: It's called a desktop operating system. I wish more developers would go back to developing for that and leave the web alone. I want my web browser to display hyperTEXT documents, with links out to other hyperTEXT documents, and occasionally accept input from me via a FORM. And that's it. I understand that opinion makes me a minority nowadays, though. Maybe we should revitalize gopher or something--something to get back to the roots of fetching, displaying, and navigating information.

Re: Google Docs will now use canvas based rendering

#237
post #99

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…

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.

Re: Google Docs will now use canvas based rendering

#239
post #116
post #99

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…

Ad blockers could still "scroll" through a website, run an AI model on it to discover the ad sections, and cut them out. Even a simple model that filters out visual animations and replaces them with a static would be useful as a large annoying component of online ads is the movement and blinking etc. that make it hard to focus on the content. Dark mode etc can, too, be implemented to work in terms of framebuffers onl…

Is there any ad blocker that blocks ads rendered within videos?

It's possible doesn't mean it's viable.

Re: Google Docs will now use canvas based rendering

#240
post #86

(googler, opinions are my own. I know nothing about this project). I really hope this fixes the large-document problem. As someone that has to deal with large specs (1000+ page MS Word documents), Google Docs does a not-so-great job of handling them. I also understand this is why many writers don't like Google Docs to write the entire book in, as things start slowing down when you get into the hundreds-of-pages. I do…

I hope so too.

But I once read, most performance problems come from all the changes that are chached for a document and yoh can fix the problem by copying the text of an old document in a new one.

This doesn't let me hope for huge performance gains.

Post reply on HN