[webkit-reviews] review requested: [Bug 19663] Image animation timers do not account for paint lag : [Attachment 21864] patch v3

[bugzilla-daemon at webkit.org]

Peter Kasting <zerodpx at gmail.com> has asked  for review:
Bug 19663: Image animation timers do not account for paint lag
https://bugs.webkit.org/show_bug.cgi?id=19663

Attachment 21864: patch v3
https://bugs.webkit.org/attachment.cgi?id=21864&action=edit

------- Additional Comments from Peter Kasting <zerodpx at gmail.com>
New patch.

This not only accounts for paint and timer lag, but skips frames as needed, and
in general deals with the case of "hidden" animated images.  Now you can switch
tabs and switch back and the image will sync to the proper place.

There are four caveats with this patch:

(1) Because we keep adding small values as doubles to calculate the desired
time for something to happen, I'm concerned this can suffer from floating point
roundoff error.  That said, the values are generally in the range of 0.05 or
higher, and we should be able to add a lot of these for a long time before we
find errors.  I think.	(My memory of how roundoff errors accumulate here is
weak.)

(2) This may need a conditional for when we are _way_ late on an animation
frame, in order to avoid doing excessive work when the user doesn't care.  If a
user has a hidden animation for 14 hours, and switches back, we're going to
iterate through 14 hours' worth of frames.  Even though we're not doing any
drawing or decoding in this process, it's still a lot of iterations.  Perhaps
we can say that once the frame is 5 minutes late, the user doesn't care about
resyncing.  That should be conservative and still fast enough to have no
noticeable impact.

(3) In the case where we want to change immediately, I do it synchronously
instead of setting a 0-wait timer.  This means the observers can get notified
of a change synchronously here.  I don't know if this is problematic.

(3) I moved startAnimation() calls in the various backends so that in the case
where we're skipping frames and need to immediately change the current frame,
we get the right frame before grabbing its bits to draw.  This reduces a weird
jumpy effect where you switch back to a tab and it draws the old frame and then
immediately a new frame.  However, as with (3), this means image observers can
get notified of the image changing, synchronously, before we actually draw the
image.	Again, I don't know how problematic this is.