Re: [Fresco-devel] animation

Nathaniel Smith wrote:

> It's true that the draw traversal shouldn't be a triggering factor in itself, 
> but there's another source of damage -- the client decides to damage something 
> (perhaps your IRC client got a message and wants to display it or something).  
> Perhaps this is the same as timers.  In any case, we have to be prepared for 
> damages happening quickly -- perhaps on a really busy IRC channel, you'll be 
> getting more than 30 messages a second :-)  Or, more realistically, perhaps 
> you're watching some high-quality video or something.

I don't understand your argument. The 30 fps limit is just that: a limit. It's there
because we assume more frames are visually not recognizable. Having more data to
display shouldn't change that. If by 'high-quality' you imply that users will
notice a higher frame rate, just increase the limit.
It's not as if damages that occure within these 30 ms get lost. They are accumulated
until the damage manager decides it's time to repair.

>>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).

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).

> Overall, though, remind me why we couple event handling and redraws like this?
>  It seems like avoiding starvation can be tricky, and while it's true that 
> input events and damage are probably correlated, I'm not sure what advantage 
> we get to actually coupling them in the code.  Stefan, maybe you can explain?

Let's see. There is a repair loop waiting for damage notice/repair requests.
Then there is an event loop waiting for input and dispatching it as appropriate.
The coupling seems to stem from the fact that it's the event dispatching that results
in screen repair requests, and, of course, from the fact that both loops are actually
taking place in the same thread. The 'wake_up' pipe is there simply because the
display server is intrinsically multi-threaded, i.e. it's not *only* this thread that
can cause damages, but any arbitrary client connection...

Regards,
		Stefan