[css-transforms] Provide a way to specify rastered content scale for transformed content

[chrishtr]

[css-transforms]

Currently, developers have no control over the scale at which to raster content with transforms. If the transform is not compositor-animated, there is only one logical answer (layout content scale plus transform). However, for performance reasons, compositor animations often work by scaling a pre-rastered bitmap in the GPU. This begs the question of the scale at which to raster that bitmap.

Each browser has its own heuristics for choosing the scale of these bitmaps, and when to re-raster them
when the scale changes. This is a problem when the heuristics fail, because the developer has no control
over details of performance and quality that are important for a high-quality rendered output.

Blink has recently done work to improve this situation. Some documents on what we're doing and background:

What we're doing: https://docs.google.com/a/chromium.org/document/d/1f8WS99F9GORWP_m74l_JfsTHgCrHkbEorHYu72D4Xag/edit?usp=drive_web&usp=docs_home&ths=true

Investigation of situation before the above and alternatives considered:
https://docs.google.com/document/d/1CsDfsMxZaM094VhTDrHXF86_rmFnpjM8xL3iEh7HWgg/edit#heading=h.omyv4h6h0sym

One thing that the above plans do not cover is control over current-frame raster scale, if the desired such scale differs from the "ideal" scale (meaning layout scale + transform). There are cases where this is desired, for example rastering at a destination scale then animating to it, to maximize quality and performance. (Note that this is how Blink actually implements declarative CSS animation rastering today)
See also this blink-dev thread for examples and related discussion:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ufwrhx_iZ7U

[smfr]

I agree this would be a useful property. WebKit tried to do it automatically, and reverted the change because it had bad perf impacts. Putting this under author control would be good.

[tobireif]

Will this allow the web developer to express eg the following?

"This SVG element will change in scale by factor 3.4, browser please prepare for swift animation."
(The animation might happen later. And it could happen over a duration, going through the full range of sizes between scale 1 and scale 3.4 .)

It's just an example - it should also be usable with HTML not just SVG, and it should support all other relevant properties and values not just transform:scale.

[tobireif]

(I guess that would allow the browser to pre-rasterize all the required sizes -> not blurry and hopefully super-fast.)

[AmeliaBR]

This really is necessary. Chrome's initial implementation of will-change for transform was so bad when it came to scale transforms that devs were dropping use of will-change completely.

During some discussion at that time (probably on Twitter, can't find it in issues here), I suggested that one option was to extend the syntax for will-change to include a list or range of values that the property might change into.

However, that extended will-change syntax could definitely get messy for transform, and would require authors to keep many parts of their code in sync.

Since the primary issue seems to be around scaling, maybe it would be better to add a dedicated max-expected-scale property. (Name TBD, need to be clear that it is a rendering hint, rather than a constraint.) As with will-change, the authoring advice could be to set the property judiciously, in advance of a likely scaling animation.

[chrishtr]

This really is necessary. Chrome's initial implementation of will-change for transform was so bad when it came to scale transforms that devs were dropping use of will-change completely.

If you can raise examples, that would be great. The "initial implementation" is definitely not what Chrome does right now.

I also posted detailed documents about what we've done since then to attempt to optimize, and reasons why we didn't pursue a raster scale spec change to date. (TL;DR: it seems hard to say what it means without over-fitting to implementation details and technologies)