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

61–70 of 161 posts

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

#61

Post by incrudible »

bryanrasmussen wrote: post #24
moonchrome wrote: post #22

Earlier quoted context omitted.

>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 ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer. well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.

Does your experience as a consumer not suggest that the amount of developers employed is, if at all, inversely correlated with software quality?

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

#62

Post by marginalia_nu »

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

That seems to be the case with a lot of modern rendering. I imagine it's why what's considered "acceptable framerates" in games keeps rising. 50 FPS on a (PAL) NES game is incredibly snappy and allows frame perfect inputs, whereas in a modern shooter it's almost unplayably sluggish.

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

#63

Post by wetpaws »

vbezhenar wrote: post #14
Traubenfuchs wrote: post #2

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?

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.

Carmack already tried to do it with Quake Live. It did not go far.

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

#64

Post by frankenst1 »

phoboslab wrote: post #51
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

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

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

#65

Post by flohofwoe »

perryizgr8 wrote: post #48
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…

> the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground Why? We can already play AAA games on our computers. It works very well, much better than anything web-based. Why would anyone put effort into replicating the same thing inside the browser?

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 out during the transition from DOS to Windows without Microsoft actively supporting game development on Windows (with the DirectX APIs), without this, AAA gaming could very well be console-exclusive now.

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

#66

Post by frankenst1 »

marginalia_nu wrote: post #62
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

That seems to be the case with a lot of modern rendering. I imagine it's why what's considered "acceptable framerates" in games keeps rising. 50 FPS on a (PAL) NES game is incredibly snappy and allows frame perfect inputs, whereas in a modern shooter it's almost unplayably sluggish.

I agree. Seems like the idea is to not worry about additional frames of lag but instead increase display refresh rates so that for example at 144Hz, 2 frames of lag "only" amount to 14ms.

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

#67

Post by frankenst1 »

baxuz wrote: post #60
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

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

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

#68

Post by afgrant »

manigandham wrote: post #43
afgrant wrote: post #25

Earlier quoted context omitted.

I don’t intend this as facetious, but how many years do you expect closed-source OS vendors to support their first-party hardware?

How many years do you expect?

For what it’s worth, personally, I expect 5 years from time of purchase.

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

#69

Post by bryanrasmussen »

incrudible wrote: post #61
bryanrasmussen wrote: post #24

Earlier quoted context omitted.

>And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer. well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.

Does your experience as a consumer not suggest that the amount of developers employed is, if at all, inversely correlated with software quality?

no, it suggests that just as the amount of developers past a certain point on a project is a drag on that project the amount of developers of a product past a certain point does not significantly increase the quality of that product.

If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the best code is no code at all but I am not especially fond of such illogical pithiness.

There may be products that it is best they not exist at all, but for products we do want to exist it follows that some number of developers of that product correlates with the quality of its existence.

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

#70

Post by flohofwoe »

marginalia_nu wrote: post #62
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

That seems to be the case with a lot of modern rendering. I imagine it's why what's considered "acceptable framerates" in games keeps rising. 50 FPS on a (PAL) NES game is incredibly snappy and allows frame perfect inputs, whereas in a modern shooter it's almost unplayably sluggish.

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).
Post reply on HN