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

891–900 of 953 posts

Re: Google Docs will now use canvas based rendering

#891

Post by saagarjha »

erlich wrote: post #764
jackcviers3 wrote: post #517

Earlier quoted context omitted.

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.

This is a first-world solution.

Re: Google Docs will now use canvas based rendering

#892

Post by asddubs »

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…

What I don't understand is why google doesn't just do what they do all the time and add 20 new APIs for it and strongarm everyone else into having to implement them too

Re: Google Docs will now use canvas based rendering

#893

Post by mort96 »

seumars wrote: post #730
dgudkov wrote: post #264

Earlier quoted context omitted.

>Google wants more control over their stuff. The web is becoming less open. That's because the old problem "web-document vs web-application" hasn't been solved properly. HTML was designed for documents. It wasn't designed for applications. No wonder as applications become more sophisticated they try to squeeze out HTML/DOM where possible.

The irony being that Docs is a web document editor

And a document editor usually has a very different feature set from a document viewer.

Re: Google Docs will now use canvas based rendering

#894

Post by mort96 »

dahart wrote: post #635
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…

> The web is becoming less open. Canvas and WebGL are both open standards, no? There are a million and one examples of losing openness, but I think this isn’t one of them.

I bet it's a feeling of, "I used to be able to right click -> view source on any web page and see source code I could understand and learn from. I can't do that anymore, which makes it less open."

Which has some truth to it, but it applies almost equally to the current HTML-rendered Google Docs I'd bet.

Re: Google Docs will now use canvas based rendering

#896

Post by incrudible »

kllrnohj wrote: post #844
incrudible wrote: post #753

Earlier quoted context omitted.

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

> 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. https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE... One would assume/hope that specifying "bitmaprende…

> One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case?

No, that's something else.

> To expand on this...

I almost wrote something like that, but then I considered that I haven't really benchmarked this. Streaming data from CPU onto the GPU is certainly possible and graphics APIs do have hints for such usage. You also don't need to convert to a texture to get arbitrary data on the screen, a trivial shader can do that for you.

If your data/transformations naturally live in RAM/CPU, that may well be the most efficient thing to do.

Re: Google Docs will now use canvas based rendering

#897

Post by netheril96 »

riho wrote: post #430
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…

In this case, I think the switch is most likely entirely based on technical merits, rather than some way of asserting more control. So with that in mind, the fact that the team behind one of Google's most interactive pieces of software has to throw up their hands and say "DOM is too slow, we gotta roll our own" should be a wakeup call for everyone working on Chrome and other browsers, but mostly for Google itself. Wh…

> Why isn't the plan here to systematically start improving DOM performance,

There are already many steps taken to improve DOM performance over these years. However, DOM is designed for documents. The performance can never be good enough when it is abused for non-document usage.

> or create APIs to more directly modify how elements are laid out and created? Why do all of this work to benefit only Google Docs?

Because other browser engines are unlikely to adopt these APIs just so that Google Docs can have better performance. Not to mention that these new APIs will take years to be present in every user's devices.

Re: Google Docs will now use canvas based rendering

#898

Post by inDigiNeous »

cxr wrote: post #805
jackcviers3 wrote: post #517

Earlier quoted context omitted.

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…

The majority of the problems with "Electron" are actually just problems with the development style used by the types of people who publish and consume packages from NPM. We've gone from a world where JS wasn't particularly fast, but it powered apps like Netscape, Firefox, and Thunderbird just fine (despite the fact that the machines of the era were nothing like what we have today) and most people didn't even know it,…

I agree, and this is something also I have witnessed in my own Electron project, where careful care was taken to write fast and memory efficient code. It doesn't really use that much memory compared to native applications when running, I've done comparisons.

I feel also that the problem is more with the style of javascript development rampant these days, where not a lot of care is taken into making memory efficient or even efficient code.

This has to do a lot of course with the high rise in people studying to become (mostly) web-developers, without any deeper degree in CS or understanding of how computers really work.

Re: Google Docs will now use canvas based rendering

#899

Post by thu2111 »

snewman wrote: post #858
mr_toad wrote: post #851

Earlier quoted context omitted.

> If you've ever had to fight with an app framework ... it usually means it’s the wrong tool for the job. I have to ask, why not a native app? Once you start bypassing every browser feature anyway, what’s the point of using a browser?

Distribution. It is so, so, so much harder to get most users to install an app, especially for casual purposes ("please add your notes to this doc") which is often how people first come to Docs.

That's a common belief but there are a lot of exceptions that mean we should question how true this really is.

1. Mobile-first, mobile-only apps.

2. Minecraft or really any game.

3. The proliferation of Electron apps that are basically downloadable versions of the website.

4. Apple's own suite of apps. Keynote is pretty darn popular.

In the case of a user who is really, really unmotivated to comment on a doc, sure. Then every click, every second counts because the user doesn't really have a fixed need to complete the task to begin with. For most other things, users are willing to download apps and may even prefer it.

It's also worth considering that Writely/Docs never really supplanted Word and is still rather feature poor even after a decade of continuous development, perhaps because they keep having to rewrite the rendering engine. If Docs was a downloadable app with a simple web-side static renderer + commenting engine, it might have obtained features that could offset any loss of casual users due to needing a download to collaborate. Especially if the download was fast, tight and transparent.

Re: Google Docs will now use canvas based rendering

#900

Post by mekkkkkk »

pjmlp wrote: post #868
mekkkkkk wrote: post #682

Earlier quoted context omitted.

What? Ubuntu Touch is an OS. Flutter is just a GUI framework, like Qt. Not sure what you're trying to say.

That Flutter is nowhere to be seen beyond As Words, the new buggy Google Pay, and a couple of cases that Google sponsored to show something in stage during Flutter conferences. And Flutter isn't even something that the whole company buys into, hence the counter movement from Android team and JetBrains with Compose or the whole PWA and Fungus Project from Chrome team. Fuchsia remains to be seen if it is going to be an…

Flutter is used in an increasing number of production apps. I'm getting frequent recruitment offers for Flutter roles. So regardless of any skepticism you might have for the longevity of the project, saying that it's only relevant for the Ad Words people is just not true. It's being adopted, and being embraced, way outside of the googleplex.
Post reply on HN