From: Chris <kc...@st...> - 2004-08-06 07:53:19
|
This patch implements XLOCK for acquire_screen, as well as the previous primitives patch. Since X is allowed to buffer calls and send them to the server en-mass, it seemed like a good idea to try and hold a lock while the screen is being drawn on.. since to me, it seems Allegro's putpixel test is XLOCK-limited, not speed-limited. And indeed, after implementation some of Allegro's primitives tests (circlefill, ellipsefill, etc, which rely on putpixel) showed substantial improvement.. more than double performance (circlefill went from ~400 per second to ~1000 per second). I wouldn't doubt that if X buffers the PutImage calls, we could see a marked improvement there, too. However, there is a slight cost. When running the demo game, using the DIGMID driver, I noticed a bit of stuttering in the sound. I can only guess that this is caused by the lock being held on the screen for too long while the screen->xbuffer conversion takes place and interrupting the input+sound thread. However, if the sound was put into its own thread (or perhaps even the timer thread), that issue would be resolved. I also tried to make the X11 driver create an XImage with the same depth as Allegro's screen, leaving X to deal with the color conversion (since if it's running on a seperate thread, it would leave the Allegro program alone while it's converting the image). However, after having to reboot my computer due to it, I don't think I'm going to try persuing this again anytime soon. - Kitty Cat |