Re: [Fresco-devel] animation

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 !

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.

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

Regards,
		Stefan