Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up[RFC] Add support for pushing already built display lists. #934
Conversation
|
@jrmuizel If you call api.generate_frame(None) it will redraw the current display list. Does this achieve what you want or is there a difference between that and what gecko requires above? |
|
My understanding is that the display list that's sent to webrender is not identical, but changed in a way that doesn't require us to rebuild the display list. It may be that this empty transaction functionality is not needed in the long term, but I'll need to investigate that further. |
|
I have some more details on the scenarios in which this happens. Imagine you have a page that's using js to continuously set the transform or opacity on some piece of content. In Gecko we'll avoid building the Gecko display list and just send an updated layer tree to the compositor. In this case we need some kind of retained version of the display list that we keep around on the gecko side so that we can send it over as needed. I think we'll be able to come a better solution to this in the long term but for now this will allow Gecko to avoid having to have it's own duplicate way of retaining parts of a display list. |
|
For that use case, the preferred API is here - #832. The way it works, roughly, is:
In this way, there is no need to maintain a client-side copy of the display list. You can just re-draw the same display list by calling generate_frame(), but specifying different values for the animated properties. Does this sound like it would cover all the use cases you know of? |
|
I guess the problem is that you don't know which properties JS might change in this case, so you end up setting every stacking context as a binding? Which isn't necessarily a problem - I don't think that will have any particularly bad side effects. |
|
Yes, #832 is the longer term api that I had in mind. And yes, we'd need to set every stacking context as a binding. How would you feel about adding api like this temporarily until we can transition to something saner? |
|
I guess that would be OK - so long as we clearly mark that it's a temporary API and will be removed. |
Gecko has the concept of 'empty transactions' where we need to get a new frame composited but aren't rebuilding the Gecko display lists. To support this we'd like to keep around a retained representation of the partial WebRender display list. One easy way to implement this is to just use a BuiltDisplayList as the retained representation and support appending them to display lists. Unfortunately, the implementation is a bit fragile because of needing to deal with ItemRanges. Hopefully, we can get rid of this eventually and avoid rebuilding the display list at all in those scenarios.
|
I have this being used in https://bugzilla.mozilla.org/show_bug.cgi?id=1344396 so it would be good to land in webrender. r? @glennw |
|
@bors-servo r+ |
|
|
[RFC] Add support for pushing already built display lists. Gecko has the concept of 'empty transactions' where we need to get a new frame composited but aren't rebuilding the Gecko display lists. To support this we'd like to keep around a retained representation of the partial WebRender display list. One easy way to implement this is to just use a BuiltDisplayList as the retained representation and support appending them to display lists. Unfortunately, the implementation is a bit fragile because of needing to deal with ItemRanges. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/934) <!-- Reviewable:end -->
|
|
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info.
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info.
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info.
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info. UltraBlame original commit: 0d411df025f5315626bd6a8bfec32d264e24cd84
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info. UltraBlame original commit: 0d411df025f5315626bd6a8bfec32d264e24cd84
This is a largely uninteresting patch that just uses the DisplayListBuilder directly. A wonderful cleanup patch will come after this. One of the more interesting pieces is the use of PushBuiltDisplayList. This is needed for handling empty transactions. See servo/webrender#934 for more info. UltraBlame original commit: 0d411df025f5315626bd6a8bfec32d264e24cd84
jrmuizel commentedFeb 27, 2017
•
edited by larsbergstrom
Gecko has the concept of 'empty transactions' where we need to get a new
frame composited but aren't rebuilding the Gecko display lists. To
support this we'd like to keep around a retained representation of the
partial WebRender display list.
One easy way to implement this is to just use a BuiltDisplayList
as the retained representation and support appending them
to display lists. Unfortunately, the implementation is a bit fragile
because of needing to deal with ItemRanges.
This change is