Thank you for explanation. 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.
czw., 10 wrz 2020 o 23:32 Adam Jackson <a...@nwnk.net> napisał(a): > On Wed, 2020-09-09 at 13:28 +0200, Marcin K wrote: > > Hello, > > I'm grabbing frames from Xvfb to use them as an opengl texture. I've > > noticed that there are 4 bytes per pixel, that suggest that there's > > an alpha channel, or something else. Is it possible to force Xvfb to > > store only RGB values in the shared memory? > > Not without hacking the code, no. There's some code in the shadow > framebuffer logic that will downconvert from 32bpp to 24bpp, but it's > meant for super-low-end cards like the Matrox G200SE or Cirrus Logic > GD-5446 that really only have depth 24 at 24bpp. You could hook it up > to Xvfb, but you'd save no memory or performance to do so, since (in > xserver 1.20 and later) the server can't render directly to 24bpp, so > you'd be drawing to a 32bpp surface and then copying from that to > 24bpp. > > At which point, since basically no OpenGL-capable GPU since like the > Intel i810 actually has an RGB24 texture format in hardware, you'd > convert _back_ to 32bpp when you upload the texture, and that > conversion would also probably be in software. > > You're almost certainly better off using a 32bpp XRGB texture in the > first place. > > - ajax > >
_______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
