Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jamie Lokier <jamie@shareable.org>]

Dan Sandberg wrote:
> When the screen is "painted" the DAC's read from the host video buffer 
> (1600x1200) and interpret it as RGB. Somewhere they "hit" the left 
> boundary of the separate viewport that you have set up and bang, on the 
> fly they switch to reading 800x600-organized data from the other video 
> buffer and interpreting it as BGR. Later on the same video line they 
> "hit" the right boundary of the separate viewport and bang they switch 
> back to reading from the main buffer and interpreting it as RGB.
> 
> As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are 
> equally active and equally often updated on the same physical screen - 
> without need for any moving data around, and without any time consuming 
> activity at all taking place as all switches are done on the fly in the 
> background by special hardware (if the board supports this).
> 
> It is like having two separate physical video boards, each with its own 
> display buffer.

Thanks; I didn't know OpenGL had that function as well as 3d rendering.

That's what the Xv extension does ("X video") - it's to provide an
overlay to be used by video players.  Xv scales the source image and
mixes it with the primary framebuffer in the way you describe.
However, Xv is intended for non-RGB colourspace source formats, so may
not be suitable for Qemu.  I don't know if Xv sometimes can support RGB.

Since Xv is supported by many video cards, even old ones without 3d,
or without working 3d drivers, I'm surprised that particular OpenGL
function isn't commonly implemented with equal performance.

-- Jamie