We always know which properties are to be updated for all CSS transitions,
so will-change doesn't make things any better. will-change can help us
decide when to layerize elements, however, which can allow us to start the
animation faster if the element wasn't already layerized.
Patrick
On Sat, Ma
"if we know in advance which properties are to be updated"
Could the CSS property will-change help with this at all?
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
> We can probably find a way to support (while not requiring) manipulation
of arbitrary CSS properties off the main thread.
Excellent! Then the issue comes down to how to get jQuery using UIWorker :)
Patrick
On Sat, Mar 21, 2015 at 9:21 PM, Robert O'Callahan
wrote:
> On Sun, Mar 22, 2015 at 8:
That's a good point about texture caching. But I don't think that there are
any advantages to painting in the compositor. Painting and layout are both
off the main thread in Servo, so nothing will block the main thread either
way. We cache display lists in the painting thread in Servo, so there's n
Another thing worth thinking about is to have some of the animated
content rendered directly in the compositor without being stored in a
layer. The Blink folks have a project along these lines. If we know that
the portion that is animated is simple enough that we can render it at
60 fps, caching it
5 matches
Mail list logo
