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

RenderingNG: An architecture that makes and keeps Chrome fast for the long term

blog.chromium.org

Post reply on HN
Print view View original

121–130 of 161 posts

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#121

Post by sirk390 »

xnx wrote: post #80
sirk390 wrote: post #33

Earlier quoted context omitted.

Https multiplied latency by three when opening websites compared to 10/15years ago where many websites were http. And also many websites include more tracking, for example Google search results used to directly send you to the result page. Now they first send you to Google so that they know you clicked but it also adds noticeable latency.

I'm pretty sure Google currently uses an async ping https://www.w3schools.com/tags/att_a_ping.asp ) instead of a redirect to log what's been clicked. It's been a very long time (if ever?) since they didn't have result click logging at all.

Indeed, I didn't know about the ping attribute. However, you will see they still do click tracking on the google image results for example. And if you check this article from 2013, you will see that they had it back then (I'm not sure when they removed it): https://chainsawonatireswing.com/2013/03/20/how-to-disable-g...

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#122

Post by flohofwoe »

Ygg2 wrote: post #118
flohofwoe wrote: post #21

Earlier quoted context omitted.

> For example with Wasm and WebGPU it's possible to create AAA games running in the browser. This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons. ...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are dea…

Is webGPU fine? https://github.com/gpuweb/gpuweb/issues/566 Basically. Rather than doing something better w3c is designing by committee so hard it somehow made worse OpenGL. A fellow contributor, that had to deal with pain of OpenGL, laughed this shit out of the gate. And I mean look at it. Who in their right mind looked at that and said, yeah that looks decent.

Ugh, please not this again. Considering the alternatives, WGSL is fine. It could have been much worse (e.g. Apple jumping ship and doing their own thing just because they have a problem with Khronos), and not requiring web apps like shadertoy to download and run a shader compiler WASM blob is also a good thing. WebGPU also needs to cover other scenarios than games.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#123

Post by jlokier »

frankenst1 wrote: post #41

Rendering is fast on Chrome, however latency is high: Chrome has 1 to 2 frames (17ms to 33ms on a 60Hz display) of additional, unnecessary input lag when compared to Firefox: https://bugs.chromium.org/p/chromium/issues/detail?id=460919

> additional, unnecessary input lag when compared to Firefox:

Not for me. When scrolling in Firefox I see pauses of about 0.5 seconds every 10 seconds or so, on all websites. After the end of each pause, scroll position jumps, as if the rendered suddenly catches up with the target position.

Similar pauses when entering text in a form

I tried playing agar.io on Firefox 93 a few days ago and it was unplayably janky.

I've been using Firefox for 20 years. This problem arrived in the last year, roughly, and has been annoyingly consistent since it arrived.

I don't like Chrome. But it feels more fluid to use because I've never noticed this level of periodic stalls. It has the feel of a difference in garbage collection strategy.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#124

Post by coretx »

flohofwoe wrote: post #107
coretx wrote: post #99

Earlier quoted context omitted.

Both Unreal Engine and Unity already have Google Stadia for a compile target ( Debian/vulkan )and it runs in the browser. As consoles have become more and more generic and all carry a browser, less money is being invested in platform specific engines because there is less relative performance increase & return on investment compared to the past. ( Games sold the platform, not the other way round ) Risks have been tak…

> ...and it runs in the browser That's not correct though, the game runs on a Linux box in Google's datacenters (granted, from a business perspective that's nitpicking - but not quite, see below, but it's a massive difference from a technical perspective). Scaling to large audiences is much more expensive with the game streaming approach though (but we'll never really know because Stadia bombed, just as all other gam…

It's not just a remote control video feed ( Unlike other game streaming platforms ) so there is tons of incentives and capability for them to offload as much as possible onto the client.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#125

Post by ithrow »

no1lives4ever wrote: post #57
justshowpost wrote: post #42

Distinguish _to be_ and _to become_. The latter is only possible if you _are not already_. Safari is efficient. Chrome becomes efficient. The latter is only possible if Chrome isn’t efficient currently.

I still dont understand why people call chrome a memory hog and safari efficient. Try loading Outlook on the web or confluence and you will see that both Safari and Chrome eat up tons of RAM and cpu.

In general safari is more efficient for me unless I opened gmail, then chrome is more efficient, gmail must have some kind of memory leak in safari.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#126

Post by jd3 »

frankenst1 wrote: post #64
phoboslab wrote: post #51

Earlier quoted context omitted.

The linked vsync-tester[1] is very cool. But it's sad to see that (at least on my system) nothing has changed since 2012[2] - Firefox still misses frames; Chrome consistently lags an extra frame. [1] https://www.vsynctester.com/ [2] https://phoboslab.org/log/2012/06/measuring-input-lag-in-bro...

Yes, it seems like smooth scrolling is prioritized over low latency. On Windows I even get 3 frames (48ms) of lag (presumably because of DWM).

I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide (through Additional Tools for Xcode 13.dmg[0] => Quartz Debug.app => Enable Vertical Sync; it only actually disables vsync if you use an external monitor and close the lid of the MacBook).

Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input lag (typing, mouse movement, etc.) throughout all of macOS.

In Firefox's about:config, after setting

user_pref("accessibility.force_disabled", 1) user_pref("general.smoothScroll", false) user_pref("general.autoScroll", true)

, I'm shocked by just how slow and laggy Chrome's builtin smooth scrolling implementation feels by comparison. In fact, it's so bad that I now open Chrome and all Electron apps with

open -a Google\ Chrome --args --disable-smooth-scrolling --disable-gpu-vsync --disable-frame-rate-limit open -a Slack --args --disable-smooth-scrolling open -a Spotify --args --disable-smooth-scrolling

You used to be able to disable Chrome's smooth scrolling with chrome://flags/#disable-smooth-scrolling, but that flag was removed for whatever reason.

I'm also surprised by how much faster Firefox's builtin middle mouse click autoscroll is compared to Chrome's ersatz AutoScroll[2] extension.

[0]: https://download.developer.apple.com/Developer_Tools/Additio...

[1]: https://pavelfatin.com/typometer/

[2]: https://chrome.google.com/webstore/detail/autoscroll/occjjkg...

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#127

Post by jd3 »

wffurr wrote: post #117
frankenst1 wrote: post #115

Earlier quoted context omitted.

Do you have any experience if this actually improves things on Windows (not ChromeOS)? AFAIK DWM is the main culprit here (1-2 frames) and `desynchronized` does not circumvent it (but avoids at best 1 frame of canvas vs DOM synchronization).

On Windows it's a modest improvement, as you saw. We would need to bypass DWM to do better, e.g. with a hardware overlay.

It's been a long time since I used Chrome on Windows — do you know if Chrome's fullscreen mode leverages exclusive fullscreen/fse/fullscreen optimizations[0]?

I'm pretty sure that's what most games use to bypass the forced DWM vsync. For example, when I used Dolphin on one of those cheap 60hz IPS LCD monitors with no internal scaler, I always preferred the lower latency + tearing in exclusive fullscreen compared to the laggy + smooth windowed mode. There was honestly such a stark difference between the two that I found the game to be unplayable in DWM's windowed vsync mode.

[0]: https://devblogs.microsoft.com/directx/demystifying-full-scr...

edit: to answer my own question, it looks like Chrome does not use exclusive fullscreen https://news.ycombinator.com/item?id=28784108

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#128

Post by jd3 »

ksec wrote: post #94
art0rz wrote: post #13

Earlier quoted context omitted.

To me it feels like bloated browser profiles makes the browsers sluggish. I get annoyed with how slow Chrome is, so I switch Firefox. After a while the Firefox profile gets bloated and I get annoyed and switch back to Chrome with a clean profile and it feels really quick again. Ad infinitum.

I dont understand how profile could make such a difference but that is also my experience as well. Everything is fast in a clean profile.

On Firefox, if you have an unbelievably large number of entries in your History, Bookmarks, and/or Downloads (your Firefox "Library" — chrome://browser/content/places/places.xhtml), you could theoretically become limited by insert/update performance in Firefox's embedded sqlite, I believe.

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#129

Post by jd3 »

jasode wrote: post #53

>A great way Chrome can render content faster is to take advantage of the multi-core CPUs and advanced GPUs present in today’s devices. Multi-core means we can do multiple kinds of work in parallel. For example, Chrome parallelizes running JavaScript, scrolling a web page, decoding an image or video, I've noticed that Firefox is not as smooth as Chrome when playing 4k video. This has been an ongoing issue experienced…

Over the past ~10 years, I've come to the conclusion that it's best to just pipe high quality video streams into a cross-platform external video player like mpv[0][1][2].

I can't remember what Firefox uses internally to decode/display different video codecs (ffmpeg like mpv? system builtins? hardware media encode/decode, like on the M1?), but I've always found that, through yt-dlp[3]/ streamlink[4] integration, a native external video player like mpv is better able to support high quality video streams without constantly dropping frames or tanking the performance of the tab/browser.

I can't put my finger on exactly why browser video streams feel so bad to me, but they do. Maybe it's the DOM overhead, or maybe it's something else. My personal takeaway is that browsers still just aren't optimized enough for fast/performant video playback.

[0]: https://mpv.io/

[1]: https://github.com/grmat/play-with

[2]: https://addons.mozilla.org/en-US/firefox/addon/play-with/

[3]: https://github.com/yt-dlp/yt-dlp

[4]: https://github.com/streamlink/streamlink

Re: RenderingNG: An architecture that makes and keeps Chrome fast for the long term

#130

Post by kfarr »

wffurr wrote: post #112
frankenst1 wrote: post #41

Rendering is fast on Chrome, however latency is high: Chrome has 1 to 2 frames (17ms to 33ms on a 60Hz display) of additional, unnecessary input lag when compared to Firefox: https://bugs.chromium.org/p/chromium/issues/detail?id=460919

On ChromeOS and Windows, you can use a desynchronized 2D or WebGL canvas to avoid the additional latency at the cost of tearing artifacts and no ability to synchronize updates with the surrounding DOM. https://developers.google.com/web/updates/2019/05/desynchron... We added this for low latency drawing in Keep and Chrome Canvas and the ChromeOS PDF annotation mode.

This sent me down a rabbit hole to see if desynchronized canvas might improve rendering three.js scenes. TLDR: No https://github.com/mrdoob/three.js/issues/16684
Post reply on HN