<div dir="ltr"><div>Thank you for explanation.</div><div>That was my deepest fear. The main issue is that I'm copying the image data real-time, and in my case, on 4* UWXGA display, this one byte means 9MB less data per frame.  <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 10 wrz 2020 o 23:32 Adam Jackson <<a href="mailto:ajax@nwnk.net">ajax@nwnk.net</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2020-09-09 at 13:28 +0200, Marcin K wrote:<br>
> Hello,<br>
> I'm grabbing frames from Xvfb to use them as an opengl texture. I've<br>
> noticed that there are 4 bytes per pixel, that suggest that there's<br>
> an alpha channel, or something else. Is it possible to force Xvfb to<br>
> store only RGB values in the shared memory?<br>
<br>
Not without hacking the code, no. There's some code in the shadow<br>
framebuffer logic that will downconvert from 32bpp to 24bpp, but it's<br>
meant for super-low-end cards like the Matrox G200SE or Cirrus Logic<br>
GD-5446 that really only have depth 24 at 24bpp. You could hook it up<br>
to Xvfb, but you'd save no memory or performance to do so, since (in<br>
xserver 1.20 and later) the server can't render directly to 24bpp, so<br>
you'd be drawing to a 32bpp surface and then copying from that to<br>
24bpp.<br>
<br>
At which point, since basically no OpenGL-capable GPU since like the<br>
Intel i810 actually has an RGB24 texture format in hardware, you'd<br>
convert _back_ to 32bpp when you upload the texture, and that<br>
conversion would also probably be in software.<br>
<br>
You're almost certainly better off using a 32bpp XRGB texture in the<br>
first place.<br>
<br>
- ajax<br>
<br>
</blockquote></div>