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

141–150 of 161 posts

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

#141

Post by fouric »

nikolay wrote: post #140
fouric wrote: post #131

Earlier quoted context omitted.

Chromium seems consistently faster than Firefox to me, and I'm pretty sure that many other people have noticed this, too. The Chromium development team intentionally optimizes for speed (at the expense of higher memory usage) more than the Firefox team does - and, if you want, you know, long battery life, this seems ideal.

Yet, nothing beats Safari on MacBooks!

I'm pretty sure because Apple is doing full-stack optimization. I'm willing to bet you that Safari has a worse trade-off than Chromium or Firefox on non-Apple platforms.

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

#142

Post by Narishma »

wetpaws wrote: post #63
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. Someone will do it. It'll be awesome. Carmack already tried to do it with Quake Live. It did not go far.

Quake Live didn't run in the browser. It used the browser as a UI for configuration and connecting to the servers but the game itself ran as a native plugin.

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

#143

Post by pwdisswordfish0 »

rakoo wrote: post #44
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…

This reminds me of Parkinson's law ( https://en.wikipedia.org/wiki/Parkinson's_law) . Paraphrased: "complexity expands so as to fill the time available for its consumption". The faster a software can be, the more things it seems to do just for achieving the same features. It's also probably another view of the Jevons Paradox: as efficiency of software increases, it gives more way for more complexity and "optimization…

> Paraphrased: "complexity expands so as to fill the time available for its consumption"

That's a very liberal paraphrasing. Parkinson's law is specifically about the amount of time that it takes to complete work (by humans, e.g. for a project deadline).

If you want to reference something that serves as good commentary about software performance, Wirth's law is right there for the using.

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

#144

Post by chrishtr »

aidos wrote: post #47

I, for one, would like to stand up and offer a digital salute to the people that worked on this. This announcement doesn't do justice to the amount of work that's gone into Chromium for RenderingNG.

(I'm the author of this blog post and lead for a large area of the work described): thanks!

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

#145

Post by chrishtr »

fenomas wrote: post #105

Does anyone here know whether/how this should affect WebGL rendering? I'm developing a browser-based 3D game, and since a week or two ago I've noticed the rendering on mac/chrome is way slower than before. In fact my game now seems to be GPU-bound, where up to now it's always been CPU-bound. I think this started right around Chrome 94 shipped, but it's hard to downgrade and check. This is only on mac; PC performance…

(I'm the author of this blog post)

The launch in Chrome 94 does not affect WebGL. It's just for HTML/CSS content.

If you can reproduce the issue and can share a URL that does so, please file a bug at crbug.com/new for us to investigate.

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

#146

Post by chrishtr »

chrishtr wrote: post #145
fenomas wrote: post #105

Does anyone here know whether/how this should affect WebGL rendering? I'm developing a browser-based 3D game, and since a week or two ago I've noticed the rendering on mac/chrome is way slower than before. In fact my game now seems to be GPU-bound, where up to now it's always been CPU-bound. I think this started right around Chrome 94 shipped, but it's hard to downgrade and check. This is only on mac; PC performance…

(I'm the author of this blog post) The launch in Chrome 94 does not affect WebGL. It's just for HTML/CSS content. If you can reproduce the issue and can share a URL that does so, please file a bug at crbug.com/new for us to investigate.

"should not affect WebGL" is probably a better way to put it. (No software has no bugs or unintended consequences...)

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

#147

Post by chrishtr »

maskros wrote: post #111

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…

(blog post author here)

Could you file a bug with an example at crbug.com/new?

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

#148

Post by fenomas »

chrishtr wrote: post #145
fenomas wrote: post #105

Does anyone here know whether/how this should affect WebGL rendering? I'm developing a browser-based 3D game, and since a week or two ago I've noticed the rendering on mac/chrome is way slower than before. In fact my game now seems to be GPU-bound, where up to now it's always been CPU-bound. I think this started right around Chrome 94 shipped, but it's hard to downgrade and check. This is only on mac; PC performance…

(I'm the author of this blog post) The launch in Chrome 94 does not affect WebGL. It's just for HTML/CSS content. If you can reproduce the issue and can share a URL that does so, please file a bug at crbug.com/new for us to investigate.

Hi, thanks for confirming!

The issue reproduces in Chrome 94 but not current mac/Firefox, so I think it's new (though with now way to downgrade Chrome it's hard to be sure). Unfortunately I don't have a shareable URL that reproduces it, but if I can find one I'll file.

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

#149

Post by fy20 »

tashoecraft wrote: post #119
fy20 wrote: post #103

Earlier quoted context omitted.

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…

I agree that my original complaint was a bit of an overreaction, but I still think my complaint about maintenance and backwards compatability is true. I've been doing frontend development for over 15 years, and SPAs for at least 10 (I started with Backbone.js), so saying 'people like me come in' is not accurate or very fair. Nowadays I mostly do backend Typescript, mainly so I can avoid issues like this.

The reason why I choose create-react-app when I first started this project was because it was most popular and recommended way to create a React app. I've hand rolled Webpack and Babel configurations before, and upgrading to the next major version is alwyays a headache, which I wanted to avoid again. Sticking to old versions is equally bad because if someone wants to try something new it's not always possible (two of the biggest frontend apps our company has are stuck on React 15). I figured it's an official project from Facebook, so will be around for a long time and well maintained, but obviously that assumption was wrong for my use case.

The upgrade instructions don't say much [0], but in my case it was a dependency of a dependency of create-react-app which was causing issues. Because of the way create-react-app is built, it isn't usually possible to downgrade or upgrade specific dependencies, or change the configuration for certain parts of it. You just have to go with what they suggest and hope that works for you - which in my case it did not.

In the backend world you will be able to find a LTS version that receives security updates and critical bug fixes for a long time, while in the frontend world your choice is upgrade to a newer version - which often has breaking changes - or stick with the old version - bugs and all.

I gave up with Vite because of the issues I had and went back to create-react-app. I've used it successfully on other - much smaller - projects, but yes for this project it isn't the right tool. Right now I'm trying to make the ejected version do what I need and fix the dependency issues, but if you have any suggestions of what else to try I'm all ears.

[0] https://create-react-app.dev/docs/updating-to-new-releases/

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

#150

Post by Ygg2 »

skitter wrote: post #120
Ygg2 wrote: post #118

Earlier quoted context omitted.

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

Had a discussion with that colleagues I spoke. He pointed me to some interesting discussion in FNA Discord.

Basically bunch of stuff listed in that blog are Rust specific uint vs int.

Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs.

I'm reminded of xkcd https://xkcd.com/927/

So rather than relying on previous work, they wrote their own somehow ugliest standard.

Post reply on HN