Re: [AD] x color conversion again (w/ responsiveness patch)

[Chris <kcat@xxxxxxxxxx>]

Elias Pschernig wrote:
> Thanks. I'll be going to apply this (sans the vsync chage, which can be
> discussed later). But we should wait until after we clarify the signals
> version crashes. Right now I see that it works without the color
> conversion for 8-bit for me, but that might just be some side effect
> hiding the real problem. Only if it turns out that 4.1.14 signals work
> for everyone, we'll have to check the changes since then.

Okay, I tested out the signals version, using my CVS checkout, and 
here's what I experienced. First, I compiled and installed only the 
debug lib, and built debug programs. expal worked fine with no 
noticeable lag in quitting or artifacting. The demo worked fine until 
after the opening FLI, when it completely froze up on a black screen. I 
had to ctrl+alt+f1 and kill the process, at which point I found this on 
my console:
-
Xlib: unexpected async reply (sequence 0x34e)!
Aborted
-
I removed the _xwin_handle_input_nolock call (effectively undoing the 
patch), modified the demo to start up with a windowed mode, and 
recompiled. This time the demo ran, but using Dirty Rectangles had a 
horrendous amount of graphical droppings.. things not overdrawn 
correctly. Then I reinstated the _xwin_handle_input_nolock call, and ran 
the demo through gdb. It ran, but ingame had the same graphical 
droppings as before.

I have a feeling it's dying in a signal, which would explain the bad 
backtrace. What I think may be happening is a function XLOCKs the 
screen, but during which the bg manager signal fires, the input handler 
sees the XLOCK and quits. Then when the previous function XUNLOCKs, it 
sees the waiting input handler call, calls it and hits an xlib async 
error. Though that wouldn't quite explain why the FLI plays perfectly 
fine... perhaps it has to do with the mouse pointer redrawing in a timer 
signal, and it's dying in that?

- Kitty Cat