Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

761–770 of 953 posts

Re: Google Docs will now use canvas based rendering

#761

Post by ufmace »

highwind wrote: post #251
throwaway894345 wrote: post #100

Earlier quoted context omitted.

I also prefer desktop-first, cloud-backed solutions, but I have quite the opposite experience. Working with MS Office has been a pain and I've been a happy Google Docs user for about 10 years. My wife who isn't an especially technical person also finds Google Docs quite a lot more intuitive and laments when she has to use MS Office products for work (she is a consultant for Microsoft including their 365 line of busin…

What makes Google Docs a better product than MS Office? Can you provide some examples of features that are better in Google Docs?

Personally, I like it better sometimes for having less features. MS Word has such a massive number of formatting features that interact in complex ways that there's plenty of ways for your document to end up formatted in a weird way and to be very difficult to figure out exactly where the switch is to make it not do something. I think one time I had a document where the entire doc was highlighted in yellow, and it took me over an hour of fiddling with various formatting boxes to figure out how to turn it off. Any word processor that doesn't have the capability to do that has some appeal to me.

Re: Google Docs will now use canvas based rendering

#762

Post by vaughan »

jhartmann wrote: post #25
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…

Performance of DOM based rendering is very problematic and not unified across browser implementations. Canvas rendering will likely increase the performance of Google Docs, and make the UX more unified across platforms. Google Docs is really an application built on the web platform. HTML DOM rendering was never intended to give developers the control they need to build fully featured high performant applications, we…

The canvas actually seems less performant when I compared it now. Scrolling is not as smooth. Click `Save as copy` and try it out.

Re: Google Docs will now use canvas based rendering

#763

Post by tshaddox »

criddell wrote: post #589
shadowgovt wrote: post #202

Earlier quoted context omitted.

JavaScript is actually quite fast these days, especially if one has a compiler in the flow to narrow it to the set of operations that are known to be high-performance. And Google would be paying a lot of that cost anyway if the DOM is the render target, because what they gain in the render algorithm being precompiled assembly they lose in the JavaScript layer pushing the wrong abstraction around to trigger all that C…

> JavaScript is actually quite fast these days Do you think a browser written entirely in JavaScript would be competitive with Chrome written in C++?

That's kinda a weird question, since it would obviously depend on what is executing the JavaScript for the browser written entirely in JavaScript. Chrome doesn't ship C++ code to your machine, they compile the C++ to native code for your particular hardware and operating system (presumably with a great many differences and performance tweaks between each compilation target).

Re: Google Docs will now use canvas based rendering

#764

Post by erlich »

jackcviers3 wrote: post #517
xxpor wrote: post #366

Earlier quoted context omitted.

I personally didn't even bother checking out VS code because it was based on electron, and so I figured the performance just wouldn't be there because it's doing all of this awkward web stuff while trying to be an IDE. I was completely wrong though. Using it, it really doesn't feel like a web app at all. It's really shocking and impressive. It feels like a text editor. Perhaps I should learn more about what they're d…

The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner. This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side. AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. Wit…

Solution: 64GB RAM. Never look back.

Re: Google Docs will now use canvas based rendering

#765

Post by quickthrower2 »

jtsiskin wrote: post #742
quickthrower2 wrote: post #561

Earlier quoted context omitted.

What do I “own” when I open a site that is a tiny HTML doc and 300kB of minified JS, plus 100 fetch calls for JSON data to render? At that point, use the DOM, use a canvas or a literal paint brush, I don’t care.

Can at least block ads still (mostly…)

That’s a good point. The only way to block now is to refuse to use the site.

Re: Google Docs will now use canvas based rendering

#766

Post by jd3 »

pcwalton wrote: post #748
jd3 wrote: post #744

Earlier quoted context omitted.

Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL HTML/CSS flex/box models in Servo/Rust. For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1]. I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITre…

I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun. XUL is 25-year old legacy technology, and using it is an exercise in retrocomputing.

Fair enough.

Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`.

I have been experimenting with performant lists (which is why I brought up the XUL tree — it's currently central to the interface, though not the final implementation for sure) — I'm currently only using the XUL window/menubar elements in order to populate the native macOS menubar.

I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc.

I love gecko and used to write XUL add-ons many years ago, so I'm already familiar with JS code modules, XPCOM, XUL, the internal browser architecture etc.

Basically, I'm now using XULRunner (`firefox --app application.ini` as previously mentioned — will eventually be stubbed into a native macOS .app/OS program) as a replacement for Electron / Chromium Embedded Framework[1].

I'm basically doing the same thing as Positron[2]/qbrt[3].

[0]: https://preactjs.com/

[1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework

[2]: https://github.com/mozilla/positron

[3]: https://github.com/mozilla/qbrt

Re: Google Docs will now use canvas based rendering

#767

Post by dunham »

DaiPlusPlus wrote: post #151
disease wrote: 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 could see how this could be faster.

At the end of the day, after the browser does all of its highly optimized processing of the dom, html, and CSS, it is issuing drawing commands that are the same as the ones you make on canvas. Canvas skips the in-between steps.

If you're in a situation where you know you want this text at this location on the page, it may be simpler to just draw what you want verses trying to arrange a DOM that will cause the browser to draw what you want. Especially if you're already doing pagination, at which point you're already doing the text breaking and layout anyway, and you're just trying to tell the browser in a high level language to give you the same low-level results that you already have in hand.

It looks like they're just doing this for text within a page, BTW. I looked at the sample document and the page scroller is DOM, and the individual pages are canvas of text, overlaid with an SVG containing the images.

The big question I have is how they manage to deal with stuff like IME (input method editors) and how they manage to work with the keyboard on mobile (looks like they don't do mobile though).

Re: Google Docs will now use canvas based rendering

#768

Post by azinman2 »

progval wrote: post #714
azinman2 wrote: post #705

Earlier quoted context omitted.

Meaning they're creating text dynamically with the click event? I'd assume that'd be chicken-and-egg where the browser wouldn't respond to the click event if there's no text to select?

No, I mean they would draw the selection themselves on the canvas. And they would get the event simply because the user clicked on the canvas.

But that's not happening, as I'm able to select text on iOS Safari and have it give me the copy/paste options above it. If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level.

Re: Google Docs will now use canvas based rendering

#769

Post by IshKebab »

dangoor wrote: post #563

In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time. Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects. edit to add: and switching to D…

Try holding down Alt on https://makepad.dev/

Such a cool feature that you can't really do with DOM based solutions (VSCode could never do this).

Re: Google Docs will now use canvas based rendering

#770

Post by sp332 »

axiosgunnar wrote: post #631
sp332 wrote: post #549

Earlier quoted context omitted.

The question is, who is sending binary WASM blobs? That ad data needs to come from an ad server, and if network requests to the ad servers are blocked, the ads will not load.

I see, that is a valid point. I suppose Google could provide dynamically including ad content into the WASM blob before serving it out to the browser, but I would agree if you said this is pure speculation.

Yeah, and it's possible today to route that data through a first-party server and randomize the file paths too. So I would say it's plausible, but moving to canvas doesn't automatically make that part worse.
Post reply on HN