Google Docs will now use canvas based rendering • Hacker News Board

Re: Google Docs will now use canvas based rendering

#751

Post by deckard1 » Wed, May 12, 2021, 9:00 PM UTC

sime2009 wrote: post #230

blacktriangle wrote: post #125

Earlier quoted context omitted.

It's not about the web being more or less open, it's about the browser playing the role of a distributed application run time. I'd argue that Google Docs is basically not a part of the web, it just incidentally happens to run in the same browser as the web does for logistic reasons.

Web apps have been around for well over a decade but some people are still struggling with the idea that a web browser can display hypertext documents and also run applications, plus a whole universe of hybrid things which lie in between these two extremes. Not everything a browser displays has to fit in the "page" paradigm.

Web 2.0 enabling web apps was always a myth. There have been web "apps" since the 1990s with CGI. XMLHttpRequest merely allowed for the moving of some of that logic to the client side.

In that respect, we've been working around the "page" paradigm since the web was practically born. It was a flawed analogy because, even back then, screen sizes and display tech varied among users. Designers still approach web design as if they are designing for print. I've always maintained that if the web were based on a vector technology (think PostScript, but obviously not PostScript) we would be in a much better place both design-wise and accessibility-wise. Content would flow in a much more controlled manner with much less room for browser interpretation and second-guessing. But people were still clinging on to the write once run anywhere (ahem, Java) naivety of the day. And likewise they really thought that you could divorce presentation from semantics and... have something that just worked? I guess? Just sprinkle on some afterthought CSS tech crap and no one will ever notice that the entire thing is flawed at a fundamental level.

Re: Google Docs will now use canvas based rendering

#752

Post by livre » Wed, May 12, 2021, 9:01 PM UTC

gentleman11 wrote: post #473

livre wrote: post #267

Earlier quoted context omitted.

I don't, we are going to have hundreds of different accessibility and IME implementations, all with different quirks and bugs and many websites won't care at all so even writing letters with accents will be a hassle (if possible at all). Or think about websites assuming your keyboard layout is US QWERTY. Or websites not properly handling subpixel rendering or retina displays (and looking upscaled and blurry). Those a…

It’s not like the w3c provides us all with rendering engines. We still use browsers which do it for us. If these canvas techs spread, everyone will rely on canvas framework toolkits that do it for them. Still not great for user power

Input methods are managed by the OS, the browser delegates control. It can't do that over a simulated input control rendered on a canvas. Also what I mean is that all these are problems already solved by browsers that follow w3c recommendations, custom rendering solutions will have to reimplement everything without access to OS APIs that make many of those things possible in a unified way.

Re: Google Docs will now use canvas based rendering

#753

Post by incrudible » Wed, May 12, 2021, 9:01 PM UTC

axguscbklp wrote: post #670

incrudible wrote: post #643

Earlier quoted context omitted.

> ... it's hard to beat just drawing on a canvas or using WebGL. Both of these APIs perform quite poorly for what they're doing. To compete with native, the web platform needs simple low-level APIs that do not have a lot of Javascript marshalling overhead and other performance cliffs. You can always build a more convenient library above low-level interfaces, but the opposite is not true.

>Both of these APIs perform quite poorly for what they're doing. When it comes to Canvas, do you mean that it actually performs poorly when putting pixels on the screen using putImageData, or do you mean that it does that fine but it performs poorly when it comes to drawing vector graphics? In either case, do you know why it performs poorly? Personally, I would be happy if Canvas just let you put raw pixel data on th…

It performs poorly in either case. For one, Javascript APIs have significant marshalling overhead.

Secondly, Canvas is often "hardware-accelerated", which can make some things faster, but also slower because this kind of immediate-mode drawing doesn't match the GPU interface well. It's particularly slow at vector graphics. Some effects would require pixel readback, which is slow for the same reason.

> Personally, I would be happy if Canvas just let you put raw pixel data on the screen and did that as well as possible.

Drawing cached Bitmaps is relatively fast in Canvas, if you don't need too many calls. Getting arbitrary data into such a Bitmap is slow, so if you want to do it every frame you may run into issues.

Re: Google Docs will now use canvas based rendering

#754

Post by svat » Wed, May 12, 2021, 9:03 PM UTC

Noticed something to try: The post links to an example document: https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

If you change the /preview to /edit you can then go to File→"Make a copy", and you'll have your own editable version of this document. If you change that one to /preview again, you (unsurprisingly) get something that doesn't use canvas, but uses the DOM with the usual div/span soup. Here's an example I created: https://docs.google.com/document/d/1RnQonRlivBogXxSl1nTZSCfR...

These two /preview versions would be a good basis for comparison (until we have examples of editable documents that use canvas-based rendering).

Visually, comparing the two /preview documents by alternating rapidly back and forth between the two tabs shows some minute differences in kerning (on only some of the lines). It might be interesting to repeat this experiment on multiple devices and see whether and in what way the differences themselves differ across devices.

One difference I've been able to find is that using the browser's in-built find doesn't work. But all the common ways of triggering search (Ctrl-F or Cmd-F, etc) trigger the search function of Docs, and that seems to work identically in both versions. And anyway the browser's find cannot find things off-page before scrolling down the page, so it's not usable in general anyway.

Re: Google Docs will now use canvas based rendering

#755

Post by [deleted] » Wed, May 12, 2021, 9:04 PM UTC

[deleted]

Re: Google Docs will now use canvas based rendering

#756

Post by vaughan » Wed, May 12, 2021, 9:04 PM UTC

If you click `Save as Copy` on the example doc you get an editable DOM-based version to compare.

The scrolling is a lot less smooth on the canvas than the DOM.

Text selection seems faster but the canvas version is not editable...

Maybe they are working out the kinks though...

Re: Google Docs will now use canvas based rendering

#757

Post by bhl » Wed, May 12, 2021, 9:04 PM UTC

snewman wrote: post #736

kannanvijayan wrote: post #724

Earlier quoted context omitted.

I'd like to chime in here as someone who has worked on optimizing the execution of your code :) Google docs specifically was one of the subjects of a particular performance push when I was working on Spidermnonkey within Firefox, and I got to see how it behaves under the hood pretty well. The thing that stands out to me the most was the giant sparse array (a regular js-native array) being used to store layout informa…

This is why I love HN. :-) However, I can't claim credit (or blame, but I would argue mostly credit) for that code. There have been three generations of the Docs editor that I know of: 1. The original, which I was involved in, was an unholy mess perched shakily atop contenteditable. As such, it contained no layout or rendering code (but did all sorts of horrid things under the hood to massage the HTML created by the…

With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?

For the majority of use cases, do you think contenteditable + view layer which precisely updates the HTML is still viable? More specifically, what do you think about open-source libraries like ProseMirror (https://prosemirror.net/) or Slate.js (https://github.com/ianstormtaylor/slate) which do that (ProseMirror uses its own view library on vanilla javascript, Slate uses React)?

I understand if you have really long documents or spreadsheets (I imagine latter is more frequent), you could maybe solve performance rendering problems with virtualization, which canvas gives more flexibility to?

Re: Google Docs will now use canvas based rendering

#758

Post by munificent » Wed, May 12, 2021, 9:04 PM UTC

jl6 wrote: post #602

munificent wrote: post #535

Earlier quoted context omitted.

> The web implies hypertext, the web implies user-agents that fulfill the user's desired agencies. That's entirely valid for many things people put on the web, but clearly not all. A document editor is not hypertext with agencies fulfilled by the user-agent. The web now supports a wide range of user experiences, and the "text + links" model is great for a subset of those, but not all. The fact that some apps are movi…

Just imagine the sheer glee on the faces of the marketing department when their SEO experts tell them there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. The web is about to get a whole lot more user hostile.

> there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads.

That was exactly true in the Flash days and yet it didn't take over the world or kill the open web.

Re: Google Docs will now use canvas based rendering

#759

Post by google234123 » Wed, May 12, 2021, 9:05 PM UTC

yhoneycomb wrote: post #291

Miraste wrote: post #168

Earlier quoted context omitted.

No, but how much longer do you think it will take them to bring this to Google and YouTube and AdWords?

Honestly if they did that I think I’d strongly consider paid alternatives to YouTube. Most of the channels I like are on curiosity stream/nebula. I’ve never subscribed because I don’t feel like I have a reason to. But that would definitely give me a reason.

Or you could just pay for Youtube which removed ads.

Re: Google Docs will now use canvas based rendering

#760

Post by tshaddox » Wed, May 12, 2021, 9:06 PM UTC

remram wrote: post #98

jerry1979 wrote: post #51

Earlier quoted context omitted.

I would not consider myself super deep in web technology, but rendering to canvas allows programmers to have pixel perfect control over the look of their applications across all devices. Currently, web developers need to "reset" lots of default rendering behaviors in every major browser to ensure that their applications look the same. After building lots of specialized UI components within the HTML standard, a progra…

Do your users care about your app looking the same or do they care about their browser looking and acting like a browser? Moving to canvas is sure to break many features such as text selection, adblocking, and accessibility. All in the name of more controls over the pixels? Are you truly doing it for the users?

I might be wrong, but I'm pretty sure Google Docs is already using a completely custom implementation of word wrapping, text layout, text selection, cursor placement, etc. It's not like it's just a with some CSS styles. Likewise, they seem to already have completely separate DOM elements that are invisible to normal browsers but can be read by screen readers. Based on the DOM on the new read-only preview document they link to, it looks like they will continue to use traditional DOM elements for some of the editing UI (just not the actual WYSIWYG editing area) and for screen readers.