combining Render's Composite + SHM's PutImage

[Nigel Tao]

On Fri, Apr 17, 2015 at 5:53 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> 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"

Ah, SHM QueryVersion will do this programatically. Thanks.


> 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.

Yes, I want to use Render. I also want to avoid copying millions of
pixels between X client and X server processes via the kernel, so I
want to use SHM too.


> 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, so what ended up working for me is to create a new (regular,
non-SHM) Pixmap, call SHM PutImage to copy the pixels to the Pixmap,
then use Render with that Pixmap as source.

For NVIDIA, does a (server-side) Pixmap always mean video RAM and not
general purpose RAM? Either way, it works for me, but it'd help my
mental model of what actually happens on the other side of the X
connection.


> 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.

Yeah, I eventually got it working without any Bad Match errors. My
window contents needed its own (depth-24) Visual (i.e. the Screen's
RootVisual), GContext and Pictformat, and my source pixels (an
offscreen pixmap that may or may not be a SHM pixmap) separately
needed its own (depth-32) Visual, GContext, Pictformat and Colormap.
I'm not sure if there's a better method, but I also made an unmapped
1x1 depth-32 Window just get that GContext. It all makes sense, in
hindsight. It just wasn't obvious to me in foresight.

I'd like to avoid using OpenGL if possible. I'm using the Go
programming language, and can write a pure Go (no C) program that uses
the equivalent of XCB. IIUC, using OpenGL requires using Xlib instead
of XCB (or an equivalent of XCB), and I'd prefer to avoid depending on
Xlib and any potential issues with mixing goroutines (Go green
threads, roughly speaking) and OpenGL and Xlib's threading model.