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

111–120 of 161 posts

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

#111

Post by maskros »

Rendering fast is nice, but when are they going to make the rendering look good? Image scaling at non-integer scales in Chrome is atrocious -- either coming out a blurry or aliased mess.

I almost always need to zoom in 20% to 50% because web designers love tiny fonts too much, and setting a minimum font size breaks their fancy layouts. This results in Chrome making a mess of all images on the page.

Thankfully Firefox resamples images so they look good at non-integer scaling factors too.

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

#112

Post by wffurr »

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.

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

#113

Post by worrycue »

frankenst1 wrote: post #102
worrycue wrote: post #82

Earlier quoted context omitted.

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.

> Both Nvidia (and AMD?) have options to reduce latency to like 1 frame in their control panels. In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency). > 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. True, if your system is not max…

> In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency).

Yes, that. Should have been more careful with my words - i.e. I meant latency of 1 frame due to the render ahead queue.

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

#114

Post by marginalia_nu »

flohofwoe wrote: post #101
marginalia_nu wrote: post #92

Earlier quoted context omitted.

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…

Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed. In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to mul…

I think we are talking about different things. I'm talking about what the GPU is doing to render a scene once the CPU has handed it off to the GPU, not what the engine is doing to produce the scene.

This pipeline: https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overv...

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

#115

Post by frankenst1 »

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.

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).

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

#116

Post by worrycue »

marginalia_nu wrote: post #92
worrycue wrote: post #82

Earlier quoted context omitted.

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…

Sorry, should have been more careful with my words. I was talking about latency due to DirectX's render ahead queue. Not total latency.

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

#117

Post by wffurr »

frankenst1 wrote: post #115
wffurr wrote: post #112

Earlier quoted context omitted.

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.

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.

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

#118

Post by Ygg2 »

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…

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.

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

#119

Post by tashoecraft »

fy20 wrote: post #103
solarkraft wrote: post #37

Earlier quoted context omitted.

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

IMO the frontend JavaScript ecosystem is a complete mess. Nobody cares about maintaining things properly or backwards compatibility. I mostly do backend, but occasionally do frontend work, and whenever I do I feel like bashing my head against a wall. Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app…

So you took something you don't understand, pushed it up, then complain when it doesn't update correctly and something goes wrong.

Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development.

Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices.

Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.

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

#120

Post by skitter »

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.

Apparently wgsl was created because SPIR-V isn't well suited for being an intermediate representation to target graphics APIs other than Vulkan itself. Some notes of intrest: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
Post reply on HN