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

Re: Google Docs will now use canvas based rendering

#731

Post by deckard1 » Wed, May 12, 2021, 8:31 PM UTC

jerry1979 wrote: post #51

notyourwork wrote: post #3

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

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…

Canvas still sucks for rendering fonts. Getting accurate font metrics is still hacky[1] and more advanced methods are still experimental[2]. Though I'm sure with Google Docs moving to canvas, some of this will be expedited. But it's yet another one of those things about web tech that anyone would half a brain would tell you should have been there day one.

[1] https://stackoverflow.com/questions/1134586/how-can-you-find...

[2] https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics

Re: Google Docs will now use canvas based rendering

#732

Post by fock » Wed, May 12, 2021, 8:31 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…

I think this is a problem of the mainstream conception seeing the future browser mainly as a monopolized, walled garden (compared to GNU/Linux, which nowadays would do everything one wanted from a computer and more) with the canvas being a kind of framebuffer.

Back when I first read about the canvas, iirc there was no fancy CSS, no fancy custom elements and making a simple doodle-element or the famous doodle-jump as a webapp was ... - well, I guess there was flash. So if you think of HTML and DOM as a GUI toolkit, it filled an important void (and continues to do so) but nowadays noone wants to use (standardized) HTML anymore, so...

If you look into tk (or nowadays tkinter) you basically see the same with the Canvas-class (I think you can't draw anything custom at all in tk easily)!

Re: Google Docs will now use canvas based rendering

#733

Post by tshaddox » Wed, May 12, 2021, 8:32 PM UTC

nine_k wrote: post #723

tshaddox wrote: post #606

Earlier quoted context omitted.

There are several other ways to prevent copying text or making it difficult, some of which probably don't impact screen readers (although I'm skeptical that many developers would be intent on preventing the copying of text while also caring about screen readers). And, of course, if the developer wants to allow copying text, that's trivial. How does canvas give a developer more ability to choose which things the user…

You cannot Ctrl+U and see the source. You cannot Shift+Ctrl+I and inspect the DOM. All you get is a bitmap, which is not even that easy to access. Much like a frame generated by a game engine.

Indeed. That's why my comparison was to image files sent from the server.

Re: Google Docs will now use canvas based rendering

#734

Post by resters » Wed, May 12, 2021, 8:36 PM UTC

It will be interesting to see if Google Docs undergoes a feature explosion and achieves parity with MS Word after the rendering engine enhancements.

I wonder what competitive pressures Google is responding to with this decision. My guess would be adding features taht facilitate selling into businesses that have significant dependency on MS Office.

Re: Google Docs will now use canvas based rendering

#735

Post by easrng » Wed, May 12, 2021, 8:39 PM UTC

endisneigh wrote: post #528

86J8oyZv wrote: post #489

Earlier quoted context omitted.

This is the endgame of putting JS/programmability (rather than just markup) in browsers at all. HTML and CSS are great for formatting documents. But, in spite of years of jQueries, Angulars, Reacts, Vues, and 10M other frameworks being implemented, HTML+CSS+JS is frankly awful for developing applications. Business needs have made us push them to be okay for enough form entry to collect credit card numbers and do bill…

I hear this take a lot. Why is HTML + JS awful for developing applications?

It wasn't designed to, it grew bit by bit with new features gradually being tacked on, so the APIs are inconsistent (For example,NodeList, HTMLCollection, and Array all have different methods and naming conventions) and poorly designed.

Re: Google Docs will now use canvas based rendering

#736

Post by snewman » Wed, May 12, 2021, 8:39 PM UTC

kannanvijayan wrote: post #724

snewman wrote: post #680

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several na…

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 various browser contenteditable engines and thus work around various problems, notably compatibility issues when users on different browsers are editing the same document). Originally launched in 2005.

2. In the early 2010s, an offshoot of the Google Sheets team launched a complete rewrite of the Docs engine which did its own editing, layout, and rendering based using low-level DOM manipulation. This was more robust, supported layout features not available in contenteditable (e.g. pagination), and generally was a much better platform. My primary contribution to this effort was to incorrectly suggest that it was unlikely to pan out. (I was worried that the primitives available via the DOM would be insufficient; for instance, to deal with mixed-directional text.)

3. This canvas-based engine, which I learned about a few hours ago when this post popped up on HN.

I don't know whether #3 is an evolution of #2 or a complete rewrite; for all I know there was another generation in between. But I imagine you were looking at some iteration of #2.

Re: Google Docs will now use canvas based rendering

#737

Post by rikarendsmp » Wed, May 12, 2021, 8:39 PM UTC

tyingq wrote: post #614

skyde wrote: post #582

Earlier quoted context omitted.

Can someone explain why https://makepad.dev/ is extremely slow and "unusable" on Microsoft Edge browser but run smoothly on Chrome? Is it because of bad WebGL perf on JavasSript perf in general?

Another possibility is code that acts differently depending on user-agent.

It most definitely does not.

Re: Google Docs will now use canvas based rendering

#738

Post by rikarendsmp » Wed, May 12, 2021, 8:40 PM UTC

ehsankia wrote: post #707

yonl wrote: post #630

Earlier quoted context omitted.

For me, it's not very fast in chrome.

Can you give a bit more flavor to "not very fast"? I'm on a measly chromebook and scrolling, selecting text, expanding directories, everything is smooth and high framerate. Is there a specific operation that is not fast? Opening it for the first time took a few seconds but afterwards it was pretty buttery.

Makepad kinda has a minimum GPU spec. It's aging-out for the people who don't have this, but some people still don't have gpu's that can bitblit their screen with a solid color.

Re: Google Docs will now use canvas based rendering

#739

Post by SquareWheel » Wed, May 12, 2021, 8:40 PM UTC

attilakun wrote: post #27

ZuLuuuuuu wrote: post #5

Maybe because I am out of loop with web development, but this sounds like a huge change to me. So instead of HTML elements, there will be just one big element, and everything will be rendered there? How will text selection work for example? Will Google Docs basically implement a GUI library like GTK, which renders everything itself, but for the web?

I'm not sure but what you are suggesting is not outside the realm of possibility. There are already projects like https://makepad.dev/ which implement their GUI on top of WebGL. (Which is arguably more challenging than implementation on top of Canvas 2D.)

Ran very smoothly for me. My only complaint is that right clicking doesn't offer a context menu, and that scroll bars don't allow snapping back to a previous position on Windows.

It would be interesting to see a project that allows integration of these native features into an otherwise canvas-like environment. Copying all the minutiae of OS features and quirks seems like an unending task.

Re: Google Docs will now use canvas based rendering

#740

Post by capitainenemo » Wed, May 12, 2021, 8:41 PM UTC

nindalf wrote: post #616

capitainenemo wrote: post #494

Earlier quoted context omitted.

After trying it for a few seconds, noticed X select-to-copy was broken, as well as the browser spellcheck feature that my daughter relies on heavily in Google Docs (where a text area can be spellchecked in french or english depending on the active spellcheck). I didn't spend more than a few seconds on it, but those were the features I immediately noticed. This is going to be a painful transition for us since she uses…

And they speak about plugins being broken in TFA. I'm not surprised that your daughter's plugin doesn't work today, because they announced the change today. Presumably, those plugins can be rewritten to adapt to canvas. Just give them time.

Well, I was referring to the built-in browser spellcheck and the X windows copy/paste. Both of those probably rely more heavily on normal native widgets. Not saying it is impossible of course. The X windows copy/paste could be done using the invisible text approach firefox uses in PDF.js. That would also help with accessibility somewhat.

But I'm not sure how they could integrate with browser spellcheck without basically going back to a less canvas-y approach. Invisible text areas surely would have layout problems aligning with the rendered font. But, I guess we'll see. I'm guessing Linux users are not a major factor in their decisions though. Firefox users probably even less so.