Because these animations only work in rigidly specified isolated static objects. Because god forbid any animation touches layout.
Well, many of those animations like opacity changes and border animations undoubtedly force the browser to re-layout and repaint the entire screen anyway. So on an actual page you'll se stutters, frame drops and ungodly CPU usage.
The only animations that will (barely) work is the `transform: translate` ones as they usually preserve the layout, and can be composited on the GPU.
> With Blink opacity, filter, and transform will skip past layout and paint after the first render.
Thanks! Didn't realize opacity was mostly fixed. In my head it as still very problematic because I know that opacity changes are very frowned upon by device manufacturers (like smart TVs). The reasons are actually mentioned in the video:
- they "don't trigger layout and can often bypass paint" (so paint isn't always bypassed)
- "compositing is not free. If you are on resource constrained devices, you really need to watch your composited layer count"
The vast majority of devices in the world out there are resource constrained: cheap smartphones are ubiquitous. But then there's also things like smart TVs etc. Hence my reaction to opacity changes :)
Well, many of those animations like opacity changes and border animations undoubtedly force the browser to re-layout and repaint the entire screen anyway. So on an actual page you'll se stutters, frame drops and ungodly CPU usage.
The only animations that will (barely) work is the `transform: translate` ones as they usually preserve the layout, and can be composited on the GPU.