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

91–100 of 161 posts

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

#91

Post by torginus »

flohofwoe wrote: post #21
vbezhenar wrote: post #14

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…

I've always wondered why nobody built Kongregate 2.0 using modern web technologies. The indie game dev scene seems to be thriving, and you can play tons of games for free on itch.io While some of them have a webplayer, it's disorganized, and the user experience is usually terrible.

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

#92

Post by marginalia_nu »

worrycue wrote: post #82
marginalia_nu wrote: post #75

Earlier quoted context omitted.

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.

That actually isn't particularly helpful.

Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio.

First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen.

It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea.

Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish.

Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.

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

#93

Post by flohofwoe »

account42 wrote: post #90
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…

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

Well that's what Google already does anyway with web APIs, except that their APIs are usually a broken mess (see WebAudio).

But apart from that, Microsoft was in a unique position to dictate standards to GPU vendors, as draconian as it sounds, this worked much better than Khronos' design-by-committee approach in OpenGL.

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

#94

Post by ksec »

art0rz wrote: post #13
theodric wrote: post #3

Earlier quoted context omitted.

Chrome became so bloated and crap and slow that in 2020 I moved over to Firefox (which has been imperfect, but better), so my anecdata suggests that browsers don't actually get faster overall, but ebb and flow as feature creep and optimization compete for dominance.

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.

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

#96

Post by user3939382 »

On the topic of improving Chrome — can we get it to stop making 2-4 attempts to put its updater in macOS launchd every time it runs? What’s the purpose of that? Obviously non-technical users didn’t remove it. Seems obnoxious.

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

#97

Post by formerly_proven »

baxuz wrote: post #81
frankenst1 wrote: post #67

Earlier quoted context omitted.

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…

DWM can un-redirect applications (skip compositing); VSync is still on, but the effects are the same as-if the application were running with VSync.

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

#98

Post by jansan »

It is a nice long term approach, but right now there should be more focus on the issue with service workers running amok and consuming a major part of the CPU without doing anything useful. The problem was worse in the past, but it is still not full ysolved and if you think about the huge number of Chrome installations running worldwide, is a huge waste of energy.

Here is one issue from the Chromium issue tracker if you are interested in details:

https://bugs.chromium.org/p/chromium/issues/detail?id=123168...

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

#99

Post by coretx »

flohofwoe wrote: post #34
nsomaru wrote: post #23

Earlier quoted context omitted.

What are the business reasons? Surely the web is just a platform for delivery? Payment etc can happen through the browser.

I agree, but tell that to the "money people" in big game studios ;) The web simply isn't on their radar, even mobile isn't for the most part. They want strong centralized platforms like Steam, EGS, Xbox, Playstation or Nintendo and a platform owner to negotiate with. This can change very quickly if there's actually some breakthrough web game, but that hasn't happened so far, and nobody wants to be the first to take t…

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 taken by big players and everything is becoming more and more platform agnostic therefore we could reasonable expect "breakthrough" when they are done milking the cow previously invested in and see them expand to a bigger market.

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

#100

Post by southerntofu »

> Chrome parallelizes running JavaScript

So i'm personally a NoScript (Tor Browser) user, but every single time i've enabled JavaScript in the past years, i wished it was not multi-threaded. Most times, a random tab will start eating most of my CPU, and i wish i had just one process-per-tab to kill to own my computer again.

On lower-end hardware especially, multi-threaded client-side scripting can make your entire computer unresponsive super quickly. I wish browser/website developers made UX testing on actual hardware (not everybody owns the latest Macbook Pro) before shipping stuff.

EDIT: To the downvoters, why? Am i missing something? Is there an easy way to make JS engines respect my resources and to keep my computer responsive when browsing the "modern" web?

Post reply on HN