Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make use of the WR property bindings support for faster animations. #19258

Open
glennw opened this issue Nov 16, 2017 · 2 comments
Open

Make use of the WR property bindings support for faster animations. #19258

glennw opened this issue Nov 16, 2017 · 2 comments
Labels
A-layout/animations A-webrender I-perf-slow Unnecessary performance degredation.

Comments

@glennw
Copy link
Member

glennw commented Nov 16, 2017

WebRender supports property bindings (currently for opacity and transform, but easy to extend). These allow modifying properties of an existing display list, and drawing it, without creating a completely new display list. This can make it much more efficient to run animations, so there is no requirement to invoke layout code at all. These are already being used by Gecko, we should also use them in Servo.

@jdm jdm added A-layout/animations A-webrender I-perf-slow Unnecessary performance degredation. labels Nov 16, 2017
@ncarrillo
Copy link
Contributor

I started looking at this (for the opacity case to start with) and I have the following questions:

  • There doesn't seem to be a notion of a unique animation ID anywhere in Servo.
    Gecko has a GetCompositorAnimationsId function.

This is needed to set a key for the PropertyBinding that gets sent in the WebRender display list. It needs to be available when constructing the display list, and also when sampling the animations in order to update their values and send them to WebRender.

This is assuming that the ProperyBinding is set eagerly for all stacking contexts. Not sure if this is the best way but I believe its what Gecko does.

Perhaps something that can easily be derived in both contexts, like the OpaqueNode property, or some monotonically increasing value that's hung off of the Fragment.

I tried going the OpaqueNode route, but the filters are constructed inside of the PushStackingContext display list which has an OpaqueNode of zero, with the real one being on an ancestor display item. Not sure if this is realiable regardless.

  • Opacity sets RestyleDamage flags such that it invokes a rebuild of the Display List. I've toyed around with modifying this by introducing another flag. I don't know much about how this might interact with the rest of layout, so I'm wary of this change.

I'm wondering if the process at update_style_for_animation can be short circuited somehow for the opacity/transform case.

Granted I am unfamiliar with the Servo code base, so I'm flying by the edge of my seat here. I'd love a mentor though :)

@glennw
Copy link
Member Author

glennw commented Nov 23, 2017

cc'ing a few people that might have thoughts on how to implement this in Servo @emilio @mbrubeck @pcwalton @mrobinson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-layout/animations A-webrender I-perf-slow Unnecessary performance degredation.
Projects
None yet
Development

No branches or pull requests

3 participants