[Webkit-unassigned] [Bug 19663] New: Image animation timers do not account for paint lag

[bugzilla-daemon at webkit.org]

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

           Summary: Image animation timers do not account for paint lag
           Product: WebKit
           Version: 526+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zerodpx at gmail.com


BitmapImage.cpp handles image animation using a startAnimation() function,
which sets a timer to call advanceAnimation() after the current frame has been
visible for its desired delay time.  advanceAnimation() does NOT call
startAnimation() again; instead, it expects the image drawing functions to call
this back when the image actually draws.  This prevents images in background
tabs from animating and eating CPU.

However, this produces a problem.  Consider an animation which tries to run at
16 FPS (= 62.5 ms per frame).  If the average latency between
advanceAnimation() finishing and the drawing functions calling back to
startAnimation() is 5 ms, then the actual time between successive frames
becomes 67.5 ms, or 14.8 FPS.  While this is not a huge difference, for sites
which sync sounds and images (e.g. ytmnd.com), this can lead to images getting
slowly out of sync over time.

A bigger problem is what happens if for some reason the drawing lag spikes
briefly (say, because the system load spikes).  If drawing takes 80 ms instead
of 5 in one of these frames, users will see a noticeable hitch.

There are two possible solutions.  advanceAnimation() could call
startAnimation() directly, which would be the most accurate method.  This would
mean images would animate in all tabs, which means the aforementioned ytmnd.com
tabs wouldn't get out of sync if users switched tabs and switched back, but
also means the browser would potentially use more CPU.  I don't think this
solution is a good idea without a lot of other motivation to change the current
behavior.

The second solution is to simply subtract off the paint delay when setting the
timer for the next call to advanceAnimation().  Except in cases where the paint
delay exceeds the desired frame duration (rare), this makes the image's
effective animation speed match its desired speed, modulo timer inaccuracy. 
The actual onscreen periods for each frame would lag the "real" animation times
by one paint delay interval, which is probably fine.

Patch to do this coming soon.


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