With the introduction hardware rasterization performance of very large SVGs has dropped significantly and is still noticeably slower on Chrome than on Firefox. Is there any chance that we will see further improvements to get old performance back? Aside from that, great work!
Interesting… now I don't know how much of this has been rolled on what Platform but I really hope this helps with some of the "jank" even small adfree webapps have. Especially on older phones (Snapdragon 820 generation and before) there still is stuff like scrolling not being smooth, animations dropping frames and general UI responsiveness being all over the place. I really hopes this gets webapps even closer to native apps.
So does this mean you're going to implement the CSS "subgrid" directives in chrome? That would boost your reliability for sure and would be super useful for devs
So, does this mean that when we have a Dark Theme, we finally won't get white pre-flash when the layout engine decides that first everything has to be drawn with a white box to "clear the area" before rendering what the developer actually asked for? This happens with Chrome's *Chrome* because render insists on happening before the UI has even finished defining its styles!
This is implementation error on the developer's side, not Chrome's. If your styles are external/relative files, the browser first needs to download those before it can compute and apply the styles to the DOM. This is what causes the flashing. Best (if not only) way to mitigate "flashes" in any browser, is to inline the CSS that defines your theme (e.g. CSS variables, specific selectors, etc.) in the HTML served directly from your server to the user. Avoid any client-side rendering as well, since that also requires scripts to be parsed, compiled and executed before it can apply any styles. Same goes with fonts and other assets that you want to have a higher priority of loading before other external assets.
@@dealloc So you're saying that the flash in *Chrome's own UI* is developer error. Yes. Chrome Developer Error. Anyhow if there's an external stylesheet, or even an internal stylesheet which comes after the UI elements (which is the case with UI themes), then Chrome should not do a paint before it resolves the styles. We shouldn't have to use Javascript to prevent painting before the page finishes loading. Chrome and Firefox are both in such a hurry to generate that FCP that they throw both performance and visual fidelity in the toilet. If you have a page with 100,000 divs, the page will take a minute to load if you allow Chrome to attempt to incrementally render it while it's loading, or 3-4 seconds if you enable display after the page is fully loaded. It's so so so bad. Try loading the US-CERT vulerabilities page. Modern Chrome and Firefox take 200x longer to render it than Firefox 2.0, and it doesn't use any CSS features Firefox 2.0 doesn't support. Warning: if you have less than 16GB of RAM it may lock up your computer.
@@linuxgeex I mentioned how you can fix it. This is not a Chrome-specific thing. This is how browsers work. You can't render something that doesn't exist until it's on your computer and interpreted/executed.
@@LarsRyeJeppesen The only thing I miss that google killed is , but some web api's are seemingly designed to benefit Google. As an example, not being able to select an input media to the speech recognition API, forcing you to use Google paid API's if you want users to be able to select the audio device for example.
@@DavisonIncorp The tag is deprecated. It's not a standard element. ALL major browsers have removed it. Do you know of any browser that still supports it? The speech recognition API is an experimental API and is not standardized yet. So I'm really confused as to which web standards are being broken precisely.
Makes you think why this architecture is so complicated... Are all steps needed? Seems it can get much more faster if you try to see what you can throw out and simplify code execution on CPU and GPU
I worked on a Windows UI framework in the mid-2010s and it had a very similar architecture. So it's not really because of Chrome legacy baggage or web APIs, for the most part. The reason to have so many steps is there are several intermediate points at which you can "save your work" in memory (e.g. with data structures or textures) so that you don't have to duplicate the previous work when things update. For example, some animations don't require repainting the content so you can reuse a texture and tick the animation without drawing anything new. Or some style changes don't affect layout so you can recompute what to draw based on the current layout tree without running the layout algorithms again.
All these work instead of simple solution: drop HTML & JS and replace with something sane and modern and well designed. Oh, and making web ... web again, instead of whole metadata collecting and add streaming platform.
Wow that's years of work in progress. Great job team. Thanks
doin' the Lord's work
Fantastic work!
I just wish google would have the same level of dedication with their other products,
This is amazing work and documentation!! Thanks
Chrome is the entry point to virtually all their products incl. areas in Android. If the engine sucks, all other projects will too.
Thank you for explaining
With the introduction hardware rasterization performance of very large SVGs has dropped significantly and is still noticeably slower on Chrome than on Firefox. Is there any chance that we will see further improvements to get old performance back? Aside from that, great work!
Amazing work.
Awesome work.
Great stuff 🎉
Is all of this already released or does something come in the future, step by step and when, in which chrome versions?
Interesting… now I don't know how much of this has been rolled on what Platform but I really hope this helps with some of the "jank" even small adfree webapps have. Especially on older phones (Snapdragon 820 generation and before) there still is stuff like scrolling not being smooth, animations dropping frames and general UI responsiveness being all over the place. I really hopes this gets webapps even closer to native apps.
While I'm extremely gland and hyped about this, I just hope everyone ends up optimizing for Firefox as well....
Can someone elaborate on the async rendering change?
So does this mean you're going to implement the CSS "subgrid" directives in chrome? That would boost your reliability for sure and would be super useful for devs
until safari implements subgrid, there is hardly any use to it.
@@riddixdan5572 Safari is the new Internet explorer, great...
It's already in Canary behind the Experimental Flag, so they're on it. Firefox meanwhile is testing masonry grid layout in Nightly.
@@christianmartinez2179 always has been
Is rendering architecture already been part of google chrome or it will be going to be the part of next chrome release ?
So, does this mean that when we have a Dark Theme, we finally won't get white pre-flash when the layout engine decides that first everything has to be drawn with a white box to "clear the area" before rendering what the developer actually asked for? This happens with Chrome's *Chrome* because render insists on happening before the UI has even finished defining its styles!
This is the single most important comment to ever exist. Everyone building an Electron app knows this pain.
This is implementation error on the developer's side, not Chrome's.
If your styles are external/relative files, the browser first needs to download those before it can compute and apply the styles to the DOM. This is what causes the flashing.
Best (if not only) way to mitigate "flashes" in any browser, is to inline the CSS that defines your theme (e.g. CSS variables, specific selectors, etc.) in the HTML served directly from your server to the user. Avoid any client-side rendering as well, since that also requires scripts to be parsed, compiled and executed before it can apply any styles.
Same goes with fonts and other assets that you want to have a higher priority of loading before other external assets.
@@dealloc So you're saying that the flash in *Chrome's own UI* is developer error. Yes. Chrome Developer Error. Anyhow if there's an external stylesheet, or even an internal stylesheet which comes after the UI elements (which is the case with UI themes), then Chrome should not do a paint before it resolves the styles. We shouldn't have to use Javascript to prevent painting before the page finishes loading. Chrome and Firefox are both in such a hurry to generate that FCP that they throw both performance and visual fidelity in the toilet. If you have a page with 100,000 divs, the page will take a minute to load if you allow Chrome to attempt to incrementally render it while it's loading, or 3-4 seconds if you enable display after the page is fully loaded. It's so so so bad.
Try loading the US-CERT vulerabilities page. Modern Chrome and Firefox take 200x longer to render it than Firefox 2.0, and it doesn't use any CSS features Firefox 2.0 doesn't support. Warning: if you have less than 16GB of RAM it may lock up your computer.
@@linuxgeex I mentioned how you can fix it. This is not a Chrome-specific thing. This is how browsers work. You can't render something that doesn't exist until it's on your computer and interpreted/executed.
Did I hear container queries?
Does Chromium get all this?
Yes. Chrome is just a Google-branded Chromium. Other browsers based on Chromium also gets these changes if they update.
Did no-one consult the Angular team when it came to naming? 🙃
I think I see why calling it Next Generation Rendering might have been a problem
No offense but you guys seriously need a naming board
with Sony
So you prefer names like Houdini? I'm mixed on "cutesey" / unique vs descriptive names for projects.
For a company called Google? Seems like a wasted effort. They operate in quirks mode
Are you using memory-safe languages?
I believe that most Chromium is (still) written in C++
is this for Chrome? or chromium?
chromium
Both
In a perfect world browsers parse TypeScript
hello guys good, very good knowledge+ideas ทักทายจากไทยแลนด์🇹🇭👁️👁️✌️✌️
When Angular is so dead that even Google doesn't bother using a different name
Nice, but how about not breaking the current web first?
how is this breaking anything?
@@LarsRyeJeppesen I didn’t say this does. They’re breaking it in other ways. Mainly AMP, and the removal of already established web standards.
@@evolutionxbox Which web standards are broken? What about the browsers that don't even implement all the standards?
@@LarsRyeJeppesen The only thing I miss that google killed is , but some web api's are seemingly designed to benefit Google. As an example, not being able to select an input media to the speech recognition API, forcing you to use Google paid API's if you want users to be able to select the audio device for example.
@@DavisonIncorp The tag is deprecated. It's not a standard element. ALL major browsers have removed it. Do you know of any browser that still supports it? The speech recognition API is an experimental API and is not standardized yet. So I'm really confused as to which web standards are being broken precisely.
TAKE ALL MY RAM!!!
Please develop chromium under GPL Licence
Is any of this spec? Multi-threaded rendering? So we're going to have to say our apps work best in chrome? lol
06:18 Jank is such a great word... almost as much flexibility as another great word that starts with the letter 'f'.
Chrome is becoming a fully fledged engine like Unreal, and I’m all in
Makes you think why this architecture is so complicated... Are all steps needed? Seems it can get much more faster if you try to see what you can throw out and simplify code execution on CPU and GPU
Let's not forget about security and s. I think those are main reasons why we need all that steps.
It's complicated because we can't get rid of browser apis otherwise old websites stop working, so we have to keep building additional ones.
I worked on a Windows UI framework in the mid-2010s and it had a very similar architecture. So it's not really because of Chrome legacy baggage or web APIs, for the most part.
The reason to have so many steps is there are several intermediate points at which you can "save your work" in memory (e.g. with data structures or textures) so that you don't have to duplicate the previous work when things update. For example, some animations don't require repainting the content so you can reuse a texture and tick the animation without drawing anything new. Or some style changes don't affect layout so you can recompute what to draw based on the current layout tree without running the layout algorithms again.
Google: **do hard works**
Microsoft: **steal and rename it to Edge**
No, Microsoft is helping them. I've been waiting on subgrid for a while and most of the development seems to come from Microsoft.
@@spartanatreyu what's subgrid?
Noob me thought this had something to do with angular :D
To honor Angular’s naming convention, I will be pronouncing RenderingNG as “renderinging”
@@jacobstamm 😆
I was thinking there is alarm manager on Angular called "ringinging"
So this is what broke my page
All these work instead of simple solution: drop HTML & JS and replace with something sane and modern and well designed. Oh, and making web ... web again, instead of whole metadata collecting and add streaming platform.
"simple solution", lol