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

881–890 of 953 posts

Re: Google Docs will now use canvas based rendering

#881

Post by manbash »

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 assume they have used CSS to apply the styles on each text span, and now they don't?

Re: Google Docs will now use canvas based rendering

#882

Post by souprock »

ehsankia wrote: post #708
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…

Did you feel the same when Maps went from HTML to Canvas? There is no factual basis for your claims. The simplest and most obvious answer is performance. Docs these days can take 5-10s to fully open, especially with comments and annotations.

Oh, maybe that is why I can no longer use Google Maps. It used to perform OK, and then one day it became hopeless.

I was thinking it might be assumptions about 3D acceleration hardware.

Re: Google Docs will now use canvas based rendering

#883

Post by VMtest »

tgiba wrote: post #367

So we're building binaries, to run them in WASM, that's running in JavaScript, which is running in browser, that is written in C++ .. is that what we're doing now?

This is misleading.

1. You write Canvas in Javascript, the article did not mention anything about Canvas in WebAssembly.

2. Although WebAssembly used to run in Javascript with asm.js, WebAssembly code can be executed by V8 engine (C++ based) already.

Re: Google Docs will now use canvas based rendering

#884

Post by darkfirefly »

missblit wrote: post #543
joelthelion wrote: post #334

Earlier quoted context omitted.

Sounds like your problem is the process that requires you to use 1000-page Word documents, not Google doc performance...

Regardless 1000 page documents _are_ the sort of things that full-fledged word processors should be able to support. Writers need to write books, readers need to read books, and computers have more than enough resources to support these use cases.

As well, I've found Google docs is hardly able to work with 20 page documents with maybe 10 or so images. It slows down rapidly when you add images.

Re: Google Docs will now use canvas based rendering

#885

Post by BlueTemplar »

remram wrote: post #496
kroltan wrote: post #134

Earlier quoted context omitted.

Very good point, users do not care that a padding is rounded up or down when they switch from their laptop to their desktop, as long as the application is usable, understandable and visually competent. But mindspace is much more important for interaction, so if their laptop is a Mac, their brain will be in "Mac mode", and "Linux" or "Windows" mode when on their other device. Respecting the platform's conventions will…

I don't think the GP was talking about the app looking consistent with the rest of the platform, but the exact opposite: the app looking the same whatever the platform. Using Flutter allows them to have the app look the same on the browser as on mobile. This means that at best it will look "Mac mode" for everyone, including Windows users; at worst it will look foreign to everyone.

Having a program look the same on a big screen with mouse+keyboard input as well as on a small touchscreen is a recipe for having a bad user experience on both.

Re: Google Docs will now use canvas based rendering

#886

Post by sgt »

lowdose wrote: post #859
saalweachter wrote: post #834

Earlier quoted context omitted.

So I've experienced Docs getting, hmm, sad once the doc you're editing gets beyond something like 30-50 pages. Does this change mean that I can look forward to being able to write hundreds or thousands of pages in a Google Doc without it getting periodically non-performant?

My M1 does not have performance issues like that with docs 3x the size. Breeze right through even with 20+ other tabs open.

Yes but most of us aren't living in the future yet. We're stuck with Intel CPU's for the time being.

Re: Google Docs will now use canvas based rendering

#887

Post by ehnto »

dahfizz wrote: post #364
ehnto wrote: post #337

Earlier quoted context omitted.

That's because the ad networks require a level of validation of their views that they prefer to have control over with javascript snippets or pixels. But it's technically a bit different, since an ad-blocker could still block those baked in advertisements while it's traditional web technology. If it's a binary blob rendered with canvas, that won't be true anymore, which I think was what the parent comment was getting…

> If it's a binary blob rendered with canvas, that won't be true anymore. The request for the ads will either happen server side or client side. If it happens client side, it can be blocked at the network level by the pihole regardless of whether a blob or js script is making the request. The request happening server side is unlikely per my previous comment.

Your previous comment doesn't explain a reason why it would be unlikely, just that it isn't. The reason it's currently unlikely is because ad-networks need to validate their views. Because you can ad-block on HTML alone, it isn't worth it to risk webmasters falsifying serverside views in order to try and get around ad-blockers because it wouldn't work. But add the ability to get around ad-blockers entirely and it becomes worth it to solve for server-side view validation.

This is the landscape as I see it:

HTML, ads loaded by user network: Can be blocked at network or in HTML.

Binary blob, ads loaded by user network: Can be blocked at network level

Serverside ads, HTML : Can be blocked by removing the ads in the HTML, and ad-networks don't like it because their views can't be validated and they could be scammed by webmasters.

Serverside ads, binary blob: Can not be blocked by network or by hiding things in the HTML, ad-networks and webmasters would want this because they can get around ad-blockers, but will need to solve view validation, the tradeoff becomes worth it.

Re: Google Docs will now use canvas based rendering

#888

Post by BlueTemplar »

Gaelan wrote: post #833
BlueTemplar wrote: post #689

Earlier quoted context omitted.

IMHO HTML documents backed by a versioning system (probably fossil or pijul rather than the overly complex git) are the way forward for documents where content is much more important than presentation.

While “text in a VCS” is a great option, it’s obviously far less usable than something like Google Docs, and you still don’t get real-time collaboration, which can be really nice.

Yeah... I'm wondering though, Fossil is based on SQLite - a database - and databases are designed to solve the issues arising when multiple users try to change the same data. (Also, fossil by default works in "autosync" mode.) So it should be "easy(er)" to make a real-time collaboration tool based on Fossil ?

P.S.: By researching this, I've stumbled on a (barebones) alternative to Google Docs : HackMD/CodiMD/HedgeDoc : https://demo.hedgedoc.org/

Re: Google Docs will now use canvas based rendering

#889

Post by draw_down »

smithza wrote: post #818
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…

Okay, if anyone else after reading Accessibility needs to be implemented from scratch felt ashamed, raise your hands with me. SW engineers suffer from assuming everyone is like them and there are no corner cases. My Mom was recently sued for violating ADA with her real estate website not working with screen readers well enough.

I’ve never worked somewhere that treated a11y as a feature, with the commensurate resources put towards implementing it. It’s always ignored and then sometimes maybe worked on as an afterthought, during a hackathon or whatnot.

In other words, even when engineers are aware of it and inclined to do something about it, mgmt still has to care, and I’ve just never seen that once.

Post reply on HN