Xvfb and number of bytes per pixel

[Marcin K]

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 <ajax at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20200911/6d85c931/attachment.htm>