> there are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change.
There's:
- reflow (most expensive)
- repaint (second most expensive)
- composition (least expensive)
The footguns in HTML and CSS are randomly scattered all over the place.
Oh? You changed a single value that wouldn't even register on any performance monitoring tool anywhere else? Oops, the browser now has to reflow the page, re-paint it, and re-compose leading to noticeable CPU and GPU spikes.
Or maybe it won't, you'll never know. Because none of these are documented anywhere and randomly change as browser internals change.
There's:
- reflow (most expensive)
- repaint (second most expensive)
- composition (least expensive)
The footguns in HTML and CSS are randomly scattered all over the place.
Oh? You changed a single value that wouldn't even register on any performance monitoring tool anywhere else? Oops, the browser now has to reflow the page, re-paint it, and re-compose leading to noticeable CPU and GPU spikes.
Or maybe it won't, you'll never know. Because none of these are documented anywhere and randomly change as browser internals change.
E.g. why would focusing an element reflow the entire document? https://gist.github.com/paulirish/5d52fb081b3570c81e3a Who knows.
Again, a recent article on HN's front page dealt with 60% CPU and 25% GPU while doing the most primitive of all animations on just three rectangles.
> I wouldn’t build a AAA 3D game engine in that, but it’s also not the intended use case.
Yes. Because the use case is displaying static pages.