Re: [Fresco-devel] animation

>>> To make Nicholas' code work, we'd have to test whether there is new
>>> damage right after the 'repair' call, and if so use a 'next_event' call
>>> that times out after some delay. Dunno whether that's currently 
>>> supported
>>> by GGI and SDL...
>>
>> I don't think that's what we want, exactly.  I agree with Nicholas's 
>> proposal; after each redraw, we:
>>   1) look to see if there are any events queued
>>      1a) if so, dispatch all of them, then continue to step 2
>>   2) look to see if there's any damage already
>>      2a) if so, dispatch a draw-traversal (and go to step 1)
>>   3) block waiting for events or need_redraw's, handling as appropriate
>>
>> This algorithm always checks for events between redraws, so we're 
>> guaranteed to be responsive to the user (though if input events come 
>> in too fast, we might not get redraws off -- I guess this could be 
>> fixed by only processing n events at a time, but I don't know what n 
>> would be -- mouse events are generated pretty quick.  I guess you can 
>> throw away old mouse events, that comes in handy).

[Thanks for the pseudo-code Nathaniel!]

> yeah, we 'compress' mouse events already. What you are suggesting is 
> just to drop
> the 30 fps limit, i.e. redrawing as many times as needed to empty the 
> damage
> vector. Having such a limit is just an optimization, done under the 
> assumption
> that the user will recognize an overloaded machine, but not a frame rate 
> higher than
> 30 frames per second (or any other number you can come up with).

The problem I'm trying to correct is entering an indefinite waiting 
period when we already have damage we know about.

Multiple damage regions are still combined whenever the damages come in 
before the redraw is done. An animation that updates every 4ms will lose 
a frame if the traversal takes 10ms. If you want to perform the redraw, 
then wait the remainder of the 33ms to smash more damage together, we 
could do that. But I want to avoid accidentally waiting 32ms after an 
event comes in, or forcing an animation that runs at 40ms to only update 
at multiple of 33ms intervals, especially in the case where there's a 
second animation running and we wait around to try to combine more of 
the damage.

Not having a waiting loop means that my pathological Graphic will cause 
the server to continually update as quickly as it can. That's exactly 
what it was designed to do. It's also a pretty good way of measuring 
performance; glxgears can get 925fps with an mp3 playing in the 
background, for example (that's X not Fresco.)

If we choose to keep the delay, then the right way to modify my 
algorithm would be to "pad" our draw traversal with the appropriate 
post-delay. That's take the current time, add 33 and store it, perform 
the traversal then wait until the time now equals the time we stored 
earlier.

Notice that this modified algorithm will still allow my strange Graphic 
to update which is a more important change then simply removing the 
33fps cap.

Nick Lewycky