add SHM to the Unix implementation

[GoogleCodeExporter]

When X11 client and server are on the same machine, there's a redundant
frame buffer that might be avoided by using SHM.

Original issue reported on code.google.com by bram.deg...@gmail.com on 2 Sep 2006 at 4:08

[GoogleCodeExporter]

I started working on the SHM support in the X11 code path.  In attachment is a 
first
"draft" of PixelToasterUnix.h.  If at least a few others find no direct issues 
with
the code, I will submit it to the repository.

HOWTO:

Currently, SHM is disabled by default, which means you actively needs to enable 
it at
compile time (rule of least surprise).  So, to test it, you of course need to
overwrite your local copy of PixelToasterUnix.h, and add the following to the
makefile of your choice (this is IMPORTANT, otherwise nothing will change ;)

add -DPIXELTOASTER_HAVE_XSHM to CFLAGS
add -lXext to LDFLAGS

If things work alright, it should print +++ USING XSHM +++ if it succeeds using 
SHM,
and +++ NOT USING XSHM +++ if a runtime issue caused to disable SHM support.

EFFECTS:

SHM avoids an extra buffer copy in the X11 calls.  This should mean that you 
should
be able to update that buffer faster.  For an 320x240 buffer on a 16-bit device 
(VNC
=), I got the following results:

floating point pixels: 1000fps -> 1300fps
true color pixels: 1900fps -> 2500fps

This is of course only the updating, no actual pixel values have been computed.

POSSIBLE ISSSUES:

They mention somewhere that you need to wait for an XShmCompletionEvent to know 
when
the update is over so that you can renew your buffer content (otherwise strange
things can happen).  However, I'm not really sure this is an issue here as we 
use
::Xflush().  Not knowing that much about X11, I wonder if that is sufficient, 
or if
we really need to hunt for that event.

Original comment by bram.deg...@gmail.com on 24 Jul 2007 at 3:49

• Changed state: Started

Attachments:

• PixelToasterUnix.h

[GoogleCodeExporter]

yeah sounds a bit too good to be true, i'll bet we have to stall out the 
pixeltoaster
update until we receive the shm completion event, otherwise we'll get 
corruption once
we update the pixels overlapped with the shm

Original comment by glenn.fi...@gmail.com on 24 Jul 2007 at 7:20