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

861–870 of 953 posts

Re: Google Docs will now use canvas based rendering

#861

Post by SilverRed »

ehsankia wrote: post #850
SilverRed wrote: post #848

Earlier quoted context omitted.

I think the panic over this is a little unfounded. For docs this makes perfect sense. My concern I guess is if this becomes the normal way of doing development, and people build HTML replacements that work using canvas. What will the impacts be. * How many browser functions will break. * Will middle click still work. * Will screen readers still work? * Will search engines/ctrl+f still work? One of the awesome things…

I don't think it'll become the normal way. If anything, the opposite is true, people making Electron apps to get to access the power of web development, instead of making native apps. It's definitely not easy, it requires you to re-implement everything from scratch. It only makes sense in cases where performance is paramount. I could imagine applications being migrated to the web doing it though, like Photoshop an th…

>it's just way too much pain for little value

I'm assuming that we will eventually have powerful HTML like frameworks built on top of canvas. So for the end developer, its just as simple as using GTK or HTML.

Re: Google Docs will now use canvas based rendering

#862

Post by random_ind_dude »

ncann wrote: post #849
random_ind_dude wrote: post #846

Earlier quoted context omitted.

The name Writely reminds me of a side project I worked on around 2010. I was not satisfied with the performance of Google Docs and its competitors at the time like EditGrid and thought (naively, as it turned out) I'd be able to develop a faster alternative. I had no idea what I was doing and thinking that using JavaScript to manipulate the DOM was going to be slow, I chose ActionScript and Flash as the language and r…

Do you mean Google Sheets instead of Google Docs?

You are correct. I meant Google Sheets instead of Google Docs. I thought I'd tackle the word processor part once I got the spreadsheet to a usable state. I do think Google Docs suite is used as an umbrella term to refer to all the Google collaboration tools like Docs, Sheets, Forms etc.

Re: Google Docs will now use canvas based rendering

#863

Post by yashap »

philosopher1234 wrote: post #811
yashap wrote: post #808

For everyone saying "Google is pushing canvas usage to kill ad-blocker effectiveness", maybe, but most of Google's ad revenue already works around ad blockers. Most of their ad revenue comes not from their display network (ads that they serve on other ppl's property), but from showing ads on their own properties. Only ~13% of their revenue comes from ads displayed on properties they don't own: https://finshots.in/inf…

That 3% you're referring to is 5.5 billion dollars, which easily justifies canvas usage. I don't personally see the connection between google docs and ads, but I think this analysis is misleading.

Fair enough, I’m sure they’d love to kill ad-blockers in general. But ... using canvas in a product that doesn’t show ads of any kind, nevermind display network ads, it is indeed a very tenuous argument that this is an anti-ad-blocker play.

Re: Google Docs will now use canvas based rendering

#865

Post by jan_schultink »

I had to put in a lot of effort to write a useable slide rendering engine for my presentation app SlideMagic that was super precise, scales up and down without issues, and still enabled clicking things in the UI. If Google has a good canvas-based engine, hopefully they will open source it as a new standard.

Re: Google Docs will now use canvas based rendering

#867

Post by girvo »

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.

While you're definitely correct, I enjoyed working with Komodo IDE which was (is?) built around XUL even up to a few years ago. A neat API for extending and hacking around on it, with quite nice discoverability. I'm sad to see it go, but it makes perfect sense as to why!

Re: Google Docs will now use canvas based rendering

#868

Post by pjmlp »

mekkkkkk wrote: post #682
pjmlp wrote: post #410

Earlier quoted context omitted.

I mean with the same adoption success.

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 another Android or follow Brillo's footsteps.

Re: Google Docs will now use canvas based rendering

#870

Post by cromwellian »

runlevel1 wrote: post #853
cromwellian wrote: post #817

Earlier quoted context omitted.

The sparse array is likely to be a protobuf. I ran into this issue with Firefox when working on Google Inbox, it was one of the reasons why the Firefox version was delayed, but there was degenerate performance with sparse arrays. (I'll note, various conspiracy theories on HN thought it was a deliberate attempt to hamper FF, when in reality, is was an unintended consequence of usage of an old protobuf format which nev…

> various conspiracy theories on HN thought it was a deliberate attempt to hamper FF I remember those being fairly rampant. I wonder if a technical blog post about the issue would have silenced some of the conspiracy theories. Regardless, there's a lesson in there somewhere. Never attribute to malice that which is adequately explained by degenerate performance of a browser pushed to its limits?

Yeah, it's primary the fault of overzealous pushing of limits. At the time we were using WebWorkers/SharedWorkers, bleeding edge CSS "compositor" behavior to achieve smooth 30-60fps animations, and lots of other stuff I don't remember. It was very easy to get off the 'golden path' of performance. Small changes in CSS or DOM structure for example would destroy layout/paint performance and require days of debugging.

Add on top of that, that Inbox was developed using a shared codebase for 3 platforms (Web, Android, iOS), the non-UI code was written in Java, while the UI code was written in JS, Java, and Objective-C respectively.

The shared "business logic" layer was cross compiled, and it was the protobuf runtime for GWT inside that was causing trouble. We "optimized" it by making it run on top of pure arrays instead of OO objects. This was a feature of GWT called 'JSO's (JavaScriptObjects) that let you pretend that raw JS objects had methods on them that they didn't, like Extension Methods in other languages.

All was good until IIRC, a utility function was introduced that did Object.keys(some protobuf array). This returns a sparse array on V8, but a reified real dense array on SpiderMonkey at that time, and so if you were unlucky enough to have a high extension field in you protobuf, you'd end up creating an array with a billion entries in it.

It was hard to forsee this because Inbox was built out of so many interacting systems. Ideally, the GWT Protobuf Compiler runtime would have had integration tests for Firefox that exercised iteration over sparse arrays with high extension number methods, but it didn't, which means the problem languished until discovered in Inbox. GWT Protobuf was probably a 20% project of someone at the time, implementing the minimal features they needed.

Also, debugging it was a nightmare, because as soon as Object.keys(big sparse array) was encountered, the Firefox debugger would essentially freeze/die, and we couldn't get iinformation out. Single-stepping through a huge ginormous bit of code after bisecting was how I tracked it down, because when I tried to console.println(object.keys(big sparse array)) it would die.

I'm not blaming Firefox, I'm not sure the JS specification even says what the right thing to do with things like Object.keys(sparse array), maybe it was unspecified/vague behavior? I'm just pointing out that there was absolutely no malice, and no desire to block Inbox from running on FF, or IE10 or WebKit for that matter. It's always basically a matter of launch schedules, late discovered bugs, and triage.

Post reply on HN