Intent to Implement: Feature Policy: animations
84 views
Skip to first unread message
Ehsan Karamad
Aug 15, 2018, 2:28:19 PM8/15/18
to blink-dev
Contact emails
Allows developers to selectively disable the use of certain CSS animations through the Feature-Policy HTTP header or the <iframe> "allow" attribute.
Slow and inefficient CSS animations add delays to paint/draw intervals. With the use of this policy-controlled feature, a developer may restrict the use of certain animations on their own web page or certain third party origins in embedded contents.
Non composited animations could significantly increase the draw interval duration. With this policy developers could disable such animations on their own sites or embedded contents and potentially achieve better user experience.
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals
This feature modifies the behavior of certain animations. During the animation getComputedStyle could return different values depending on whether or not the animation is enabled.
EhsanK
Aug 15, 2018, 5:26:01 PM8/15/18
to blink-dev
Brian Birtles
Aug 16, 2018, 8:11:10 PM8/16/18
to blink-dev
2018年8月16日木曜日 3時28分19秒 UTC+9 EhsanK:
I'm concerned about this feature policy.
As you are aware, the set of animations that can be run on the compositor varies by engine and frequently changes. WebKit, I believe, can animate clip-path on the compositor. Gecko is working on animating background-color on the compositor. However, Gecko does not yet run filter animations on the compositor. Under the lowest common denominator approach, engines will be required to disable animations even in cases where they would run on the compositor (e.g. Blink would be required to disable filter animations).
Furthermore, even within a given engine, the conditions required for animating on the compositor can be subtle. For example, in Gecko transform animations on SVG elements can be run on the compositor (which I believe is not true of other engines, or was not previously) but Gecko won't run that animation on the compositor if the SVG element has a rendering observer (e.g. is used in -moz-element or a mask). As a result, the feature policy cannot reliably guarantee smooth/efficient animations.
"Problems with this, and a better solution"[1] proposes adding syntax for specifying the allowed properties which addresses these concerns to some extent, but raises others.
For example, in my testing I see that my browser can animate 'transform' and 'clip-path' smoothly but not 'border-color', so I set allow="animations(transform,clip-path)". However, on other browsers animating 'clip-path' is slow so the feature policy is ineffective. Furthermore, it puts the burden on the maintainer of the page to keep checking what properties can be animated smoothly so that, if in one year's time all browsers can animate 'border-color' smoothly, they must remember to update the string.
It's a tricky problem but I can't think of a good way to approach such a time-sensitive and engine-sensitive performance issue other than a feature policy that simply restricts all declarative animations.
[1] https://github.com/WICG/feature-policy/blob/master/policies/animations.md#problems-with-this-and-a-better-solution
As you are aware, the set of animations that can be run on the compositor varies by engine and frequently changes. WebKit, I believe, can animate clip-path on the compositor. Gecko is working on animating background-color on the compositor. However, Gecko does not yet run filter animations on the compositor. Under the lowest common denominator approach, engines will be required to disable animations even in cases where they would run on the compositor (e.g. Blink would be required to disable filter animations).
Furthermore, even within a given engine, the conditions required for animating on the compositor can be subtle. For example, in Gecko transform animations on SVG elements can be run on the compositor (which I believe is not true of other engines, or was not previously) but Gecko won't run that animation on the compositor if the SVG element has a rendering observer (e.g. is used in -moz-element or a mask). As a result, the feature policy cannot reliably guarantee smooth/efficient animations.
"Problems with this, and a better solution"[1] proposes adding syntax for specifying the allowed properties which addresses these concerns to some extent, but raises others.
For example, in my testing I see that my browser can animate 'transform' and 'clip-path' smoothly but not 'border-color', so I set allow="animations(transform,clip-path)". However, on other browsers animating 'clip-path' is slow so the feature policy is ineffective. Furthermore, it puts the burden on the maintainer of the page to keep checking what properties can be animated smoothly so that, if in one year's time all browsers can animate 'border-color' smoothly, they must remember to update the string.
It's a tricky problem but I can't think of a good way to approach such a time-sensitive and engine-sensitive performance issue other than a feature policy that simply restricts all declarative animations.
[1] https://github.com/WICG/feature-policy/blob/master/policies/animations.md#problems-with-this-and-a-better-solution
EhsanK
Aug 17, 2018, 11:10:10 AM8/17/18
to blink-dev
Thanks Brian for the detailed feedback!
A first meta comment: I invite you to please do file some of the issues raised here as github issues against the animation policy on the github page. The decision on the v0 version is not finalized and perhaps the policy could use more feedback and corrections.
Other Comments inline.
On Thursday, August 16, 2018 at 8:11:10 PM UTC-4, Brian Birtles wrote:
2018年8月16日木曜日 3時28分19秒 UTC+9 EhsanK:I'm concerned about this feature policy.
As you are aware, the set of animations that can be run on the compositor varies by engine and frequently changes. WebKit, I believe, can animate clip-path on the compositor. Gecko is working on animating background-color on the compositor. However, Gecko does not yet run filter animations on the compositor. Under the lowest common denominator approach, engines will be required to disable animations even in cases where they would run on the compositor (e.g. Blink would be required to disable filter animations).
Yes I do agree that the set of composited/optimized animations might differ from engine to engine. I also agree that under the common denominator approach, at this point, might leave us with only a few options. This is a set of animations picked for the policy for now and currently implemented behind the flag - and by no means final. Specially given that the longer-term aim for this policy to to become parametric based on "list values" [2] which would leave the animation selection to the developers themselves. Meanwhile, I encourage you to kindly file issues on certain animations that perhaps should be included in the first version.
Also, FWIW, this policy is also blocking the common set of animations which are not composited on any browsers.
Furthermore, even within a given engine, the conditions required for animating on the compositor can be subtle. For example, in Gecko transform animations on SVG elements can be run on the compositor (which I believe is not true of other engines, or was not previously) but Gecko won't run that animation on the compositor if the SVG element has a rendering observer (e.g. is used in -moz-element or a mask). As a result, the feature policy cannot reliably guarantee smooth/efficient animations.
Yes I agree to determine exactly when a certain animation can be composited is notrivial (given the example above). However, the expectation is that an animation is considered to be part of the policy if it is perhaps mostly optimized. By having such an animation enabled we hopefully get performance gains by having it run on GPU; but if not it will run on CPU in which case the performance is no worse than before using the feature. The way I think about the policy is that it should block the animations which are almost uniformly non-optimzied across most browsers.
"Problems with this, and a better solution"[1] proposes adding syntax for specifying the allowed properties which addresses these concerns to some extent, but raises others.
For example, in my testing I see that my browser can animate 'transform' and 'clip-path' smoothly but not 'border-color', so I set allow="animations(transform,clip-path)". However, on other browsers animating 'clip-path' is slow so the feature policy is ineffective. Furthermore, it puts the burden on the maintainer of the page to keep checking what properties can be animated smoothly so that, if in one year's time all browsers can animate 'border-color' smoothly, they must remember to update the string.
It's a tricky problem but I can't think of a good way to approach such a time-sensitive and engine-sensitive performance issue other than a feature policy that simply restricts all declarative animations.
Agreed with the fact that finding a consistent set of efficient animations across all browsers is nontrivial. But this policy does serve as a development tool as well: a developer of a larger website project could enable/disable certain set of animations to determine what breaks and what needs to be changed. The could use this tool to a) find violations for a pre-determined set of animations which are known/believed to be more efficient, b) experiment with different sets to find the best bundle. As for the examples scenario, if it turns out that in a good number of instances certain animations such as 'transform' provide good performance gains by running over a GPU then perhaps this is an animation that should be selected as the bundle of enabled animations for the policy.
On a separate note, as it is common with all feature policies, indirectly a policy such as animations could provide browsers with indications` to potentially use fast paths for certain operations in a page. Although that might be difficult to make use of anyway.
Thanks,
Ehsan
Brian Birtles
Aug 19, 2018, 8:50:50 PM8/19/18
to ekar...@chromium.org, blink-dev
Hi Ehsan,
Thanks for following up on this. As suggested I've filed issues over in WICG:
- [Feature policy: animations] Compositor accelerated animations should not be allowed
- [Feature policy: animations] Description of animations needs review
- [Feature policy: animations] What does "blocking" an animation mean?
Best regards,
Brian
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/nRNPNwlRS6E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ab2fb1e0-2c3d-44b8-bcf2-45ed584ab87e%40chromium.org.
Reply all
Reply to author
Forward
0 new messages