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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2004-07-14 at 10:54 -0700, Chris wrote:
> Okay, this got here right as I clicked send on the last email. I'll 
> respond to this then try getting to bed again.
> 

Heh :)

> Elias Pschernig wrote:
> > Those for who only CVS crashes
> > hopefully see the same than me, and the patch* fixes it.
> 
> I'm not sure if the CVS version I have includes your color conversion 
> patch. I think it does, since I'm get a bunch of graphical glitching 

Well, it contains *the* color conversion patch. It actually just enabled
the generic color conversion routines with the X11 driver. (My patch
partially disables that, when using signals and an 8-bit mode.)

> (which closer inspection reveals the graphics getting warped badly, 
> which is why it left dropping behind because the drs system didn't know 
> it was misplaced there). Double buffering seems to be uneffected 
> (expectedly, since it's drawing 8bit->8bit), and page flipping just has 
> the warp flash for a frame and then clear away.. both expected behavior 
> with the color conversion patch malfunctioning. The only unexpected 
> behavior is that the double buffer never seems to warp.. maybe it has to 
> do with image size? With my input handler patch, the demo only died once 
> with an async error (which I have yet to get again), otherwise I just 
> have the graphical glitches. What resolution do you run the game at?
> 
> A revised theory... something in the color conversion patch causes 
> images of certain sizes at certain positions (or just randomly) to 
> sometimes warp. And for some, the image/double buffer tries to draw out 
> of bounds (SIGSEGV).
> 

Well, if you get around to it some time, try downloading the 4.1.14
release and see if you get the same there. So we can be sure these
glitches only were introduces recently. But I'm quite sure you are
seeing the same than me, there's no reason my system should behave
special.

>  > Wasn't there a similiar problem not allowing floating point inside
>  > timers, when using non-threaded versions?
> 
> The problem in DOS was that you couldn't use the FPU stack inside an 
> interupt, presumably because the OS-level interupt handler didn't 
> properly save and restore the stack (thus you would end up getting 
> garbage in the FPU stack when you returned from an interupt). I have no 
> idea if signal interupts have the same problem.
> 

Well. My theory is: *Something* in the asm-color-converters doesn't get
preserved over an interrupting signal. I.e., the signal enters somewhere
inside the asm, and therefore, a register or flag is modifed. Or, since
we do no X11 locking in the signals version, the memory the asm
converters are accessing is volatile and is invalidated when a signal
occurs?

-- 
Elias Pschernig