Live data from Hacker News

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

blog.chromium.org

81–90 of 161 posts

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

#81
post #60

Earlier quoted context omitted.

Reading that thread, it seems that Firefox has some other tradeoffs, but I might be wrong. https://youtu.be/E3wTajGZOsA

Yes, there are also platform specific tradeoffs involved. For example on Windows >8, you can't disable VSYNC on an OS level. Only option to disable VSYNC is to circumvent DWM which must be supported by the individual application (e.g. by starting in exclusive fullscreen, which is not supported by Chrome).

An important thing, as far as I'm aware of, is that if you have a Gsync monitor, you want vsync enabled, but you don't want your GPU to max-out usage-wise or reach the max refresh rate of your monitor:

https://www.youtube.com/watch?v=YR0vNs0ZdWI

Not sure how it behaves on windowed modes. For instance, Doom Eternal's fullscreen is actually composited on the desktop (could be a Vulkan thing), but doesn't seem to suffer from DWM overhead, latency wise.

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

#82

Earlier quoted context omitted.

Old game consoles and home computers had much better input latency so that input was usually 'realized' within the same video frame. This is much harder to do on modern hardware and operating systems (and frame rate is also only one aspect of button-to-screen latency).

The pipeline rendering architecture is probably also in part to blame. It doesn't degrade particularly gracefully. Modern GPUs have staggered rendering where one frame is rendered while the previous frame is postprocessed (that's a bit simplified, it's more like a waterfall with a bunch of different steps). That sort of a conveyor belt-like operation always induces latency, and a struggling GPU increases the time it…

Both Nvidia (and AMD?) have options to reduce latency to like 1 frame (edit: due to render ahead queue; not total latency) in their control panels. You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time.

Display latency from LCDs are another factor - something that was completely absence on CRTs.

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

#83

How come processors and browsers become faster every year but the internet feels as slow and bloated as ever? How long can this x% faster continue? There must be some theoretical optimum, how far are we away?

What the browser giveth, the web developer taketh away. I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.

Recent exceptions:

1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history.

2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc.

Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from.

Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.

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

#84

Earlier quoted context omitted.

Popular apps will be as slow as user can tolerate. Because if they're not slow enough, it invites developers to introduce another abstraction layer. Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs. For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll b…

>For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome. You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets). You pay the sandbox tax even in the ideal scenario and there are plenty pathologica…

> And what are the benefits exactly ?

Slightly off topic but I wonder if WASM and the web can provide a “fixed” virtual platform for games.

A lot of games are heavily platform dependent, when the hardware for those platforms die the games will be nigh unplayable without a huge remastering effort or building an emulator of said platform which may or may not be technically feasible - even on PC we have games breaking as hardware advanced, e.g. Deus Ex had to be patched to work with multi core CPUs if I remembered right.

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

#85

Earlier quoted context omitted.

Mostly independence from the whims of platform owners who control the distribution, a space to try out quirky new ideas, and less hassle both for devs and users (no lengthy download or installation process for instance). This is much more important for indie devs than AAA devs though (the current problems of the web platforms are not really 'AAA specific'). Also, don't forget that PC gaming could very well have died…

> Mostly independence from the whims of platform owners who control the distribution Agreed, however platforms that restrict app distribution also heavily restrict what you can run via the browser (see Ios). So the benefit is minimal. > a space to try out quirky new ideas This has nothing to do with web. Look at steam's catalog. Plenty of whacky quirky stuff is available. > no lengthy download or installation process…

> Why do you think AAA games will not need downloading assets and logic?

As internet connections get faster it makes sense to stream/prefetch data directly from CDNs as needed instead of downloading everything upfront.

> Look at steam's catalog. Plenty of whacky quirky stuff is available.

Agreed, but that's the exception, not the rule. Look at Apple's app store ecosystem for a counter example where apps and developers are banned on Apple's whim. This couldn't happen on the web.

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

#86
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…

gfx.webrender.all no longer has any effect, as webrender is enabled everywhere by default (if supported by your hardware, which it probably is)

It would be very helpful if you could capture a performance profile while playing the video, by going to profiler.firefox.com and following the instructions.

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

#87

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.

Perhaps the blame lies with outlook and confluence then?

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

#88

Earlier quoted context omitted.

Popular apps will be as slow as user can tolerate. Because if they're not slow enough, it invites developers to introduce another abstraction layer. Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs. For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll b…

>For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome. You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets). You pay the sandbox tax even in the ideal scenario and there are plenty pathologica…

> GB sized assets

You don't need such assets to make good games anyway. The obsessions with AAA are unhealthy - many of the best games are not AAA at all, but strictly indie.

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

#89

How come processors and browsers become faster every year but the internet feels as slow and bloated as ever? How long can this x% faster continue? There must be some theoretical optimum, how far are we away?

What the browser giveth, the web developer taketh away. I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.

I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today.

I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though.

But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.

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

#90

Earlier quoted context omitted.

Popular apps will be as slow as user can tolerate. Because if they're not slow enough, it invites developers to introduce another abstraction layer. Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs. For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll b…

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

> TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.

You want one browser vendor to implement a proprietary API and then have the ramining vendors try to emulate it?

Post reply on HN