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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2004-07-14 at 09:06 -0700, Chris wrote: 
> 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?
> 

Well, i get the crashes with --disable-pthreads from CVS, without
applying any other patches. But I do not get them with 4.1.14, or with
that small patch disabling the paletted asm color converters.

Here's the complete checks I ran, always with:

./configure --disable-shared --enable-static --enable-dbglib --disable-
stdlib --enable-dbgprog --disable-modules --disable-pthreads && make
depend

And optionally --disable-asm:

                            --disable-asm
4.1.14              |  ok |
CVS                 |  X  | ok
CVS with patch*     |  ok |

so, 4.1.14 as well as CVS with my patch works completely, and so does
the C only version.

X means:
ex12bit and expal crash at once
demo crashes after the mode selection
test works in 15,16,24,32bit, and crashes in 8bit when doing any of the
timed tests where it draws a lot (tried putpixel,hline,vline - putpixel
needs a bit longer to crash)
exgui works

the crash is always:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078750144 (LWP 4788)]
next_block_8_to_32 () at src/misc/icolconv.s:306

Going from just my above results, I would of course apply the no-8bit-cc
patch to fix current CVS (and adding to the TODO to investigate it). The
gdb output, the patch, and the --disable-asm, all show the 8-bit asm
colorconverter as source of the problem. (the difference between MMX/no
MMX is, the MMX version crashes a it sooner. But also no-MMX asm
crashes.)

But seeing the results of others, it looks like there's some more
mystery, causing different things for everyone. Well, for now, I'm
waiting for more test reports. Eventually we will find out.

I think - those for who also 4.1.14 crashes, experience a general
problem with the signals version. Those for who only CVS crashes
hopefully see the same than me, and the patch* fixes it. If neither
crashes for someone, then all the better :) If 4.1.14 does not crash for
someone, and also CVS with my patch*, then that would be bad, since I
couldn't apply it :P

* re-attached the patch, to avoid confusion with all the input-patches
floating around, which have nothing to do with this (except they caused
us looking on the signals version).

-- 
Elias Pschernig

Index: src/x/xwin.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/x/xwin.c,v
retrieving revision 1.61
diff -u -p -r1.61 xwin.c
--- src/x/xwin.c	11 Jul 2004 10:33:10 -0000	1.61
+++ src/x/xwin.c	13 Jul 2004 20:37:27 -0000
@@ -1461,6 +1461,12 @@ static int _xwin_private_colorconv_usabl
       /* For usable true color modes visual must be TrueColor or DirectColor.  */
       return 0;
    }
+   #ifndef ALLEGRO_MULTITHREADED
+   else if (_xwin.screen_depth == 8) {
+      /* TODO: Find out why it crashes otherwise */
+      return 0;
+   }
+   #endif
    else if ((_xwin.fast_visual_depth == 16)
        && (_xwin.rsize == 32) && ((_xwin.gsize == 32) || (_xwin.gsize == 64)) && (_xwin.bsize == 32)
        && ((_xwin.rshift == 0) || (_xwin.rshift == 10) || (_xwin.rshift == 11))