On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade <est...@chromium.org> wrote:
> In this case, something is not working as expected (at least on
> Linux), because when I test on the download shelf slide animation, the
> number of AnimationProgressed calls is exactly what one would
> calculate based on the frame rate and duration, even if I put a
> Sleep(1000) in the middle of the callback.
>
That sounds very wrong. Please treat that as a bug.
> I'm not sure how to deal with this other than to create a separate queue
> of
> > "events triggered by animations" and let later updates overwrite earlier
> > ones that haven't yet been processed; that would be really hard to plumb,
> > though.
>
> Hmm, why would we need a separate queue for that? Seems we could
> search for other animation events when dequeueing an animation event
> on the normal message loop. But the above fix seems cleaner/safer
> anyway.
>
I mean for eventstriggered by animation events. Let's say the download
shelf animation resizes the download shelf, which resizes the content area,
which sends a message to the renderer to relayout at the new size. Now the
renderer process his a resize cued up that in theory should be canceled by a
future resize from the animation but in practice wouldn't be.
Of course this example is bogus because IIRC the renderer already collapses
resize requests, to deal with mases like "moving the mouse around a lot
while resizing".
PK
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
