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

571–580 of 953 posts

Re: Google Docs will now use canvas based rendering

#571

Post by fwip »

warkdarrior wrote: post #559
delroth wrote: post #397

Earlier quoted context omitted.

"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.

All web pages are editable currently, they are editable via Javascript. Not sure the distinction you are making is meaningful. The only thing we are missing is a good edit UI.

Google Docs is what happens when you write a good editing UI.

Re: Google Docs will now use canvas based rendering

#572

Post by p_j_w »

WD-42 wrote: post #462
stefan_ wrote: post #237

Earlier quoted context omitted.

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.

I didn't believe you at first, but then I gave it a try. Yes, they actually built an email client from which you cannot copy text: https://gallery.flutter.dev/#/reply

That's a demo for a gallery, not an e-mail client.

Re: Google Docs will now use canvas based rendering

#573

Post by notjustanymike »

ainar-g wrote: post #565
notjustanymike wrote: post #97

It makes a hell of a lot of sense, even from a QA perspective alone. Canvas is going to be far more predictable as a rendering target than the wide swath of browsers they manage now. The DOM certainly has a place, but if you've looked at Google docs rendered output you'd notice it left web standards behind a long long time ago. This is an application which happens to be served on the web, not a traditional website. I…

How would you test something like that using Selenium or something like that?

I can't speak for Google, but my company does 3D medical rendering (BioDigital). To test that our 3D engine is appropriately rendering the content, we use Cypress with image diffing. I'm sure Google has a way more advanced QA process for docs, but that'd be an option.

Re: Google Docs will now use canvas based rendering

#574

Post by nofunsir »

slver wrote: post #555
nofunsir wrote: post #508

Earlier quoted context omitted.

I honestly believe they WILL implement copy paste... ... along with tracking exactly what you copied, when, where you hovered your mouse, inserting all sorts of features into your copied piece of “plain text” ... along with the ability to force-turn off copying from server side whenever it benefits them. You WILL use ChromeOS (by another name) and you WILL like it

All of this is done without canvas. Maybe less drama would help.

> All of this is done without canvas.

Currently it’s pretty easy to get around such blocks. Compare with how hard it is to get around modern, proper DRM.

I have faith this implementation will be modern and proper, as the fate of the ad industry and those who rely on it, rely on it.

Re: Google Docs will now use canvas based rendering

#575

Post by Sleepytime »

thekyle wrote: post #156

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.

Google and their AI won't have any issues, but their competitors probably will.

Re: Google Docs will now use canvas based rendering

#576

Post by Leherenn »

moshmosh wrote: post #89
MaxBarraclough wrote: post #66

Earlier quoted context omitted.

> What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. Ok, but it's not trivial to build complex web-based applications that don't do exactly that. This is why there are so many frameworks out there that take care of that problem for you. React isn't the only one. Angular, Vue, and Svelte also handle this for the developer, using various different approaches. It's n…

I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs…

I disagree, I prefer to Google something and have it instantly in my browser instead of having to find and install yet another app, then uninstall it when I'm done with it. Especially for stuff I only use once/rarely.

Also, I might be using the latest iPhone, an old Android, Windows or Linux, or hell maybe my TV browser, and it's most likely going to work. The app wouldn't exist on at least half those platforms.

There certainly are issues with webapps, but well done it can a really good UX.

Re: Google Docs will now use canvas based rendering

#577

Post by Secretmapper »

trinovantes wrote: post #470
Tyriar wrote: post #308

I wrote the terminal canvas renderers in VS Code that has been called out a few times here. Initially I implemented a canvas renderer using just a 2d context to draw many textures which sped things up "5 to 45 times"[1] over the older DOM renderer. Since then I moved onto a WebGL renderer[2] which was mostly a personal project, it's basically the first canvas renderer but better in every way since it works by organiz…

Do you think the large performance benefits can be achieved for any general web app (e.g. if I rewrite my Vue app's render functions to using a canvas instead of the DOM) or is the canvas' benefits mainly for niche workloads?

I remember Flipboard using canvas to render their UI before using react, which has the same idea, you can look at the repo and their post about it:

https://github.com/Flipboard/react-canvas

Re: Google Docs will now use canvas based rendering

#578

Post by xxpor »

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…

I just in the past month upgraded my main work laptop from 16 GB from 40 GB (8 GB soldered + 32 GB SODIMM). So your point is granted, but on the other hand, DDR4 prices have collapsed ~50% from 2018 (I couldn't believe it either, given all of the other semiconductor issues).

Re: Google Docs will now use canvas based rendering

#580

Post by zerkten »

Tyriar wrote: post #542
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…

This isn't entirely the fault of Electron though, but the convenient data types exposed in a web environment. Beyond the baseline memory of running Chromium, you could use various tricks to keep memory very low such as minimizing GC (eg. declare variable up front, not within loops), use array buffers extensively, shared array buffers to share memory with workers, etc.

Is there a good guide to these techniques in modern JS? How likely are they to remain viable long-term?
Post reply on HN