[webkit-dev] Enable REQUEST_ANIMATION_FRAME on all ports? (was Re: ENABLE flag cleanup strawman proposal)

[Dimitri Glazkov]

James, this is a crazy cool mail. I found it full of TILs and think
its guts totally should be on our blog. Bonus points: pictures.

:DG<

On Mon, Sep 26, 2011 at 9:48 PM, James Robinson <jamesr at google.com> wrote:
>
>
> On Sun, Sep 25, 2011 at 6:52 PM, Darin Adler <darin at apple.com> wrote:
>>
>> On Sep 25, 2011, at 12:20 AM, James Robinson wrote:
>>
>> > The TIMER based support for RAF is very new (only a few weeks old) and
>> > still has several major bugs. I'd suggest letting it bake for a bit before
>> > considering turning it on for all ports.
>>
>> Got it.
>>
>> > Fundamentally I don't think this feature can be implemented reasonably
>> > well with just timers, so port maintainers should take a really careful look
>> > at the level of support they want to have for this feature when deciding if
>> > they want to support it.
>>
>> This may contradict the recommendation above. If the timer-based version
>> is too low quality then maybe we shouldn’t put ports in the position of
>> shipping with a substandard implementation rather than simply having the
>> feature omitted.
>
> Perhaps if I expand on my concerns a bit it'll be clearer what the right
> option is.
> The goal of requestAnimationFrame is to allow web authors to have
> high-quality script-driven animations.  To use a concrete example, when
> playing angry birds (http://chrome.angrybirds.com/) and flinging a bird
> across the terrain, the RAF-based animation should move the bird at a
> uniform rate across the screen at the same framerate as the physical display
> without hitches or interruptions.  An additional goal is that we shouldn't
> do any unnecessary work for frames that do not show up on screen, although
> it's generally necessary to do this in order to satisfy the first goal as
> I'll show below.  There are two main things that you need in order to
> achieve this that are difficult or impossible to do with a WebCore Timer: a
> reliable display-rate aligned time source, and a source of feedback from the
> underlying display mechanism.
> The first is easiest to think about with an example.  When the angry bird
> mentioned above is flying across the screen, the user should experience the
> bird advancing by the same amount every time their display's update
> refreshes.  Let's assume a 60Hz display and a 15ms timer (as the
> current REQUEST_ANIMATION_FRAME_TIMER code uses), and furthermore assume
> (somewhat optimistically) that every frame takes 0ms to process in
> javascript and 0ms to display.  The screen will update at the following
> times (in milliseconds): 0, 16 2/3, 33 1/3, 50, 66 2/3, 83 1/3, 100, etc.
>  The visual X position of the bird on the display is directly proportional
> to the time elapsed when the rAF handler runs, since it's interpolating the
> bird's position, and the rAF handler will run at times 0, 15, 30, 45, 60,
> etc.  We can thus determine the visual X position of the bird for each
> frame:
> Frame 0, time 0ms, position: 0, delta from last frame:
> Frame 1, time 16 2/3ms, position: 15, delta from last frame: 15
> Frame 2, time 33 1/3ms, position: 30, delta from last frame: 15
> Frame 3, time 50 0/3 ms, position: 45, delta from last frame: 15
> Frame 4, time 66 2/3 ms, position: 60, delta from last frame: 15
> Frame 5, time 83 1/3 ms, position: 75, delta from last frame: 15
> Frame 6, time 100 0/0 ms, position: 90, delta from last frame: 15
> Frame 7, time 116 2/3ms, position: 105, delta from last frame: 15
> Frame 8, time 133 1/3ms, position: 120, delta from last frame: 15
> Frame 9, time 150 0/3 ms, position: 150, delta from last frame: 30 (!)
> Frame 10, time 166 2/3 ms, position: 165, delta from last frame: 15
> Frame 11, time 183 1/3 ms, position: 180, delta from last frame: 15
> Frame 12, time 200 0/0 ms, position: 195, delta from last frame: 15
> What happened at frame 9?  Instead of advancing by 15 milliseconds worth,
> the bird jumped forward by twice the normal amount.  Why?  We ran the rAF
> callback twice between frames 8 and 9 - once at 135ms and once at 150ms.
>  What's actually going on here is we're accumulating a small amount of drift
> on every frame (1.66666... milliseconds, to be precision) between when the
> display is refreshing and when the callbacks are being invoked.  This has to
> catch up sometime so we end up with a beat pattern every (16 2/3) / abs(16
> 2/3 - 15) = 10 frames.  The same thing happens with a perfect 16ms timer
> every 25 frames, or with a perfect 17ms timer every 50 frames.  Even a very
> close timer will produce these regular beat patterns and as it turns out the
> human eye is incredibly good at picking out and getting annoyed by these
> effects in an otherwise smooth animation.
> For this reason, you really need a precise time source that is tied in to
> the actual display's refresh rate.  Not all displays are exactly 60Hz - at
> smaller form factors 50 or even 55hz displays are not completely unheard of.
>  Additionally the normal clock APIs aren't always precise enough to stay in
> sync with the actual display - particularly on windows it's really hard to
> find a clock that doesn't drift around all over the place.
> The above analysis assumes that all calls are infinitely fast and there's no
> real contention for system resources.  In practice, though, this is rarely
> the case.  It's not uncommon that the system will temporarily get overloaded
> and has to make tradeoffs between maintaining a high framerate and remaining
> responsive to user input.  In Chromium, we have some logic to ensure that we
> load balance between handling input events and painting to ensure that
> processing one type doesn't completely starve the other.  In a multi-process
> environment, such as WebKit2 or Chromium, there needs to be coordination
> between the two processes in the non-composited path in order to paint a
> bitmap and get it onscreen.  If this logic is all operating completely
> independently from the rAF scheduling then it's very easy to end up
> triggering callbacks at a time when the browser can't produce a frame
> anyway, or painting without invoking the rAF callbacks even if they should
> be invoked.  A related issue is what to do when the rAF callbacks themselves
> cause us to be unable to hit our target framerate - for example by
> invalidating some portion of the page that is very expensive to repaint.  In
> that case, the ideal behavior is to throttle down the rAF callback rate to
> what we can sustain, which requires some feedback from the rest of the
> graphics stack.
> Architecturally I think that WebCore is the wrong place to address these
> issues.  WebCore is responsible for generating repaint invalidations and
> passing them out to the WebKit layer via ChromeClient, and it's responsible
> for painting content when the WebKit layer asks it to.  Otherwise, all of
> the frame scheduling logic that would be relevant to rAF lives outside of
> WebCore in the port-specific layers.  Determining a valid clock source for a
> given graphics stack and deciding when to produce new frames are also highly
> port-specific.
> Note that I don't think that using a timer is necessarily evil in all cases.
>  With some rendering architectures or graphics libraries, it may not be
> possible to produce a better solution.  We still use a timer in chromium in
> our non-composited path, although it is integrated with our frame scheduling
> and back pressure logic.  Additionally a timer is quite easy to code up and
> works "pretty well" most of the time (although you can be sure that your
> pickier users will complain).  There are also some benefits to providing
> this API even without great scheduling - for example a port can throttle the
> rAF callbacks for non-visible content or tabs without the backwards compat
> issues doing the same thing for setTimeout() would have, leading to
> dramatically lower power and resource consumption in some cases.
> I still think it's dangerous to provide this as a default for all ports to
> fall back on, because I worry that if it's there ports will use it without
> considering the issues I mention above.
> - James
>>
>>    -- Darin
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>