[Webkit-unassigned] [Bug 82646] [chromium] Idle painting is not sufficient to pre-paint animated layers and delay animation start time

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 30 17:49:16 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=82646





--- Comment #3 from Dana Jansens <danakj at chromium.org>  2012-03-30 17:49:16 PST ---
You're right, this can happen.

Here's what Ian realized today though. We currently wait for the animation to start on the impl thread but this is wrong. It needs to start exactly at the time when WebKit gives it to us so it is in sync with WebKit.

This means if we make a very slow paint and then commit it, we'll miss the animation anyways.

I think in general, prepainting should be enough in the second commit. Even when we don't prepaint and a tile comes on screen, about:tracing seemed to say we were easily able to paint it before the next frame.

We are seeing a lot of bad effects around this use case because of the hitching in the times, and this is because we are starting the animation late on the impl thread.. if Ian's observations today hold up to the 24 hour test :)

Either way, I expect that this will become a non-issue once he fixes the synchronization issues we're seeing when main thread commits. And if it's the way I think we'll fix it, then we will be far better off starting the animation as fast as possible and prepainting non-visible stuff to try catch up after the first commit.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list