combining Render's Composite + SHM's PutImage

Aaron Plattner aplattner at
Thu Apr 16 12:53:19 PDT 2015

On 04/13/2015 02:33 AM, Nigel Tao wrote:
> On Fri, Apr 10, 2015 at 10:23 PM, Nigel Tao <nigeltao at> wrote:
>> Even where SHM CreatePixmap works, I can only seem to create a
>> depth-24 pixmap, which defeats the purpose of alpha-blending if the
>> shared-memory image's alpha channel is implicitly fully opaque. If I
>> try to create a depth-32 pixmap, I get a Bad Match (8) error. I
>> noticed that the Screen's RootVisual (0x20, see xdpyinfo snippet
>> below) that I passed to CreateWindow corresponded to a depth-24
>> VisualInfo, so I tried passing different VisualInfos to CreateWindow
>> (either 0x21 or 0x60), but got another Bad Match (8) error from
>> CreateWindow.

SHM pixmaps are only allowed if the driver enables them.  It's the 
application's job to check before trying to create one.  In NVIDIA's 
case, we disabled them because they can't be accelerated by the GPU and 
are generally terrible for performance.

You can query it with "xdpyinfo -ext MIT-SHM"

I'm not sure why you're using shared memory to begin with.  Especially 
if you're just doing alpha blending, you're almost certainly much better 
off using OpenGL or the X11 RENDER extension to let the GPU do the 
graphics work.

At least for NVIDIA, you're going to need to copy the pixels into video 
RAM at some point anyway.  If you can upload the pixels to the GPU once 
and then leave them there, that's your best bet.

> Ah, creating depth-32 pixmap and pictures works... once I set a
> colormap, which makes sense.
> Also, I seem to need a border pixel (or border pixmap), which is less
> obvious to me.
> One last thing: by using a depth-32 visual and colormap, I no longer
> get expose events when my window manager moves my window off-screen.
> Instead, the previously painted pixels are restored. I guess this
> makes sense, since the window's pixels (of depth 32) are no longer
> shared with the screen's pixels (of depth 24). However, I'm worried
> about having many such windows, all taking up memory even if I
> minimize or iconify them. Is there a way for my program (the X client)
> to tell the X server to drop the backing pixmap when idle / minimized?

The X server will use the Composite extension automatically to redirect 
the contents of your window into a backing pixmap when its depth doesn't 
match the depth of its parent.  There's no way around this because the 
windows have different pixel formats.

Generally, you only want to use the 32-bit visual if you expect the 
alpha channel of your window to be used by a composite manager to blend 
your window with whatever's below it.  If you're just doing alpha 
blending yourself in order to produce opaque pixels to present in a 
window, you should use a 24-bit visual and do your rendering using 
OpenGL or an offscreen 32-bit pixmap.


More information about the xorg mailing list