RE: [Fresco-devel] animation

>===== Original Message From Stefan Seefeld <[email protected]> =====
>Nick Lewycky wrote:
>> Nathaniel Smith wrote:
>>
>>> ===== Original Message From Nick Lewycky <[email protected]> =====
>>> Stefan Seefeld wrote:
>>>
>>>> Nick Lewycky wrote:
>>>>
>> [snip]
>>
>>>> the 'event loop' the repair thread is sitting in is receiving input
>>>> from
>>>> the input devices as well as a pipe the ScreenManager is connected to.
>>>> If you call 'need_redraw' on any graphic, it will result in the
>>>> ScreenManager to 'wake_up' the repair thread by means of that pipe.
>>>> That's about as event driven as you can get.
>>>
>>>
>>> You're right. A quick hack to delay the need_redraw request until after
>>> the traversal has completed fixes everything. Thank you.
>>>
>>>
>>> Hmm, how silly.  Shouldn't redraw requests that occur during the
>>> traversal queue up to be processed after the traversal finishes?  Or
>>> if this is what happens, then shouldn't the repair thread check that
>>> queue?
>>
>>
>> We can poll whether there's damage at any time. The question is, should
>> we poll before or after we block for events? If we poll before, a
>> Graphic like mine would cause the system to never process events because
>> it would never enter the event loop. Right now, we poll after. Would it
>> help to add a hasEventsWaiting API to the Console so that we can check
>> it? The logic would be redraw, check for waiting events and if there are
>> none, move on to the check for current damage? And if there are events,
>> calling next_event will NOT block? That sounds cleaner to me.
>
>First of all, as you say yourself, you'v got a 'rogue graphic' that only
>works because we never redraw more than 30 times a second. Never rely on
>that though !

He's got a pretty weird example, it's true :-)  The server should be robust 
against this, though, of course.

>I'm not sure we should encourage people to generate redraw requests from
>inside the draw traversal. Clients shouldn't even care when the draw 
traversal
>happens, not to speak of take any action. Damages are caused either by timers
>or as a consequence of event handling (i.e. either by focus changes or by
>handle_event calls). These are the only semantic changes happening in the 
server.

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.

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

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?

-- Nathaniel