Re: [AD] X11 unresponsiveness

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-07-12 at 13:10 -0700, Chris wrote:
> Elias Pschernig wrote:
> >  void _xwin_handle_input(void)
> >  {
> > -   if (_xwin.lock_count) return;
> > -
> >     XLOCK();
> >  
> >     if (_xwin_input_handler)
> 
> As I made the comment in #allegro, I don't think it's a good idea to 
> just flat out remove this. The signals version of Allegro will block all 
> other running code (in the program's process), so what would happen is 
> XLOCK would eventually halt the process as something else has the lock, 
> but since no other code is running, the lock would never be released. 
> The signals would keep piling on top of each other as X never gets 
> unlocked until you get a nice crash.
> 
> I think a better solution would be to restore that line, but encase it 
> in #ifndef ALLEGRO_MULTITHREADED/#endif gaurds. This would mean the 
> pthread-based version would get rid of the input problem, although the 
> signal-version would still have it, until something better can be found.
> 

Yeah, of course, I understand now. So the signals version inherently has
that problem. I can see some solutions:

1. A hackish way to fix e.g. expal would be to set a flag whenever
_xwin_handle_input had to return without processing input. Then inside
_xwin_set_palette_range check for that flag, and if it is set, busy wait
until it is unset. This means that all X11 drawing now blocks, but input
is never blocked twice in a row.

2. Going a step further, we count how often/long the input was blocked.
And then, as soon as we are more than a certain time behind, let's say
50ms, the flag is set. The next time the input function is called, it
will process the events from the last 50ms, and reset the flag. Whatever
drawing function is blocking (busy waiting) on it continues.

The consequence: If something works already, it keeps working. Input
will never lag more than the threshold, so the flag will never get set,
all drawing operations work like now. In the case where the signals
version currently freezes or lags (expal, demo game), the flag will get
set after the lag threshold is reached, and now further drawing
operations block until input was read. The signals version again is
responsive.

3. And a third idea coming to mind. What if we simply add a call to
_xwin_handle_input before the XLOCK in drawing functions? There could
also be a time threshold to not call it if there was already a signal in
e.g. the last 50 ms.

Oh, and

4. Leave it as it is. Discourage use of the signals version which is
inherently laggy.


I think, 2 would be the cleanest method. 3 is quite similiar. 1 has the
problem that all drawing operations would get slower. I'm strongly
against 4. Any maybe someone here comes up with an even better idea than
my 3.

-- 
Elias Pschernig