On 04/13/2015 02:33 AM, Nigel Tao wrote:
On Fri, Apr 10, 2015 at 10:23 PM, Nigel Tao <nigel...@golang.org> 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.
http://stackoverflow.com/questions/3645632/how-to-create-a-window-with-a-bit-depth-of-32
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.
--
Aaron
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
