Re: [AD] Thoughts on speeding up X

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-07-30 at 05:30 -0700, Chris wrote:
> This is pretty much just a random musing I had earlier tonight. The 
> reason Allegro's X driver is so slow is somewhat obvious after looking 
> through the source and realizing what it's doing. It's using a double 
> buffer for the screen bitmap, and doing an equivilant of a blit to the X 
> display whenever a piece of it changes. Granted it only does this once 
> per operation (putpixel, blit, hline, etc), but I think the full 
> consequence of this is much more serious.
> 
> In X11, you start off with a double buffer just by using the driver as 
> noted above. All gfx operations are done to this memory bitmap (an 
> XImage). Now, when you add a color conversion into the mix (by selecting 
> a different screen depth than the current X display), it's using two 
> buffers (the XImage of X's real depth, and one of Allegro's screen 
> depth). So we're double buffering a double buffer. On top of this, games 
> usually employ a double buffer themselves for 3 buffers. No, we're not 
> done yet.. to add to it, X itself can also be double buffering us. So 
> that gives us a potential of 4 seperate buffers a single gfx operation 
> has to go through before not only displaying, but getting control back 
> for the program to continue.
> 
> My initial thought after realizing this is.. why the initial double 
> buffer? AFAIK, X has drawing primitives we can map getpixel, putpixel, 
> line, and the like, to. It also has an image structure that we can 
> potentially hack and use to blit Allegro bitmaps through directly to the 
> X display. This should significantly speed up matching-color-depth 
> operations. We can probably leave the double buffer for when color 
> depths don't match (after all, the docs do state that using a different 
> depth can impair performance.. although this also applies to fullscreen 
> X11 too, not just windowed), but include a config option to not allow 
> this like Windows does.
> 
> Thoughts? Ideas?
> 

Well, if someone would start writing a new X11 gfx driver, we could
include it. Allegro should be designed to handle it - after all there's
a DirectX and a GDI driver in windows - so there could be a second X11
driver (maybe replacing the current one at some point).

I actually started writing a new keyboard and mouse driver for X11, but
it may be some time until it's ready, since I have to completely redo
the handling of displays - there's a separate display for event
processing, and no more need for XInitThreads. This was necessary, since
I couldn't find out how to hande Latin1 characters without XIM, which
requires its own display.

But, I'll write more details in a few months, once the driver is
(hopefully) ready. In any case, if you plan on doing a new gfx driver,
try to keep it modular, don't mix X11 input stuff with gfx stuff, like
the current xwin.c does.

Also, get Peter's A5 core implementation, it's the best X11 examples I
could find (just, its keyboard module is as flawed as the current
Allegro one), and except the fact is uses C++ - it looks very well
designed.

-- 
Elias Pschernig