On Sunday, March 22, 2015 at 3:28:13 AM UTC+9, Patrick Walton wrote:
> One remaining issue is how to deal with jQuery-style animations that are
> done with setTimeout(). They have to contend with everything else on the
> DOM/script thread to avoid breaking the HTML/JavaScript event loop
> semantics
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
On Sun, Mar 22, 2015 at 8:03 AM, Patrick Walton wrote:
> A hypothetical requestAsyncAnimationFrame() API whose callback had no
> general access to the DOM and window object (though you could, for example,
> pass specific DOM objects in to mutate their styles) would solve this
> issue. Google's ol
Admittedly I haven't looked at precisely what jQuery does, other than to
verify that its animations do run on the main thread. requestAnimationFrame
doesn't solve the problem, though, because rAF callbacks run on the main
thread with full access to the DOM and JS heap. So if we tried to run them
co
On Saturday 2015-03-21 11:27 -0700, Patrick Walton wrote:
> 2. *Avoid going through style recalculation for transitions.* Style
> recalculation (including CSS selector matching and layout object
> construction) fundamentally has to access the DOM. But there is no need to
> actually do this to updat
On 2015-03-21 2:27 PM, Patrick Walton wrote:
One remaining issue is how to deal with jQuery-style animations that are
done with setTimeout(). They have to contend with everything else on the
DOM/script thread to avoid breaking the HTML/JavaScript event loop
semantics. I've brainstormed ideas for
Hi everyone,
I've been thinking about ways that Servo's architecture can result in user
experience improvements in common Web patterns today. One particularly
relevant thing that's becoming clear is that Web pages often animate CSS
properties that require reflows in current Web browsers. Google ha
11 matches
Mail list logo
