Wine: DirectDraw over Direct3D

[Aric Cyr]

Raphael <fenix <at> club-internet.fr> writes:

> 
> On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote:
> > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr:
> > > What is slow with ATI cards?  It seems that you should only need basic 3D
> > > acceleration to do what you propose.  Is fglrx missing something that
> > > would be required for 2D rendering?
> >
> > Texture upload is very slow. glReadPixels, glWritePixels and friends take
> > ages.  That means that blt, Lock, and Unlock is really slow.
> > There is some hope at least: Xine and Mplayer can play videos over OpenGL
> > really fast, maybe we can find out how they do it.

Texture upload is not too bad with the ATI drivers, but gl{Read/Write}Pixels
will be horribly slow on most any video card.  I would hope that DDraw is using
textures and not direct framebuffer writes (which I believe is what Roderick
mentioned).  Especially, glTexSubImage2D() which should be even faster than
glTexImage2D().

> for glReadPixels, glWritePixels
> you can use the frame buffer object extension (or/with pbuffers) :)

while glReadPixels and glWritePixels can be used with FBO, there would be no
performance improvment compared with using them on a standard framebuffer.  The
only potential advantage to using the FBO extension would be if we created the
framebuffer to match the ddraw pixel format, but it doesn't seem that paletted
framebuffer formats are supported by FBO anyways.  For other RGB(A) formats that
do not match the current pixel format, it could be a win.  For example if the
Xserver is running 24 bit colour, we should be able to attach a 16bit colour FBO
and use that.  This might allow us to work around unsupported colour depths,
such as in the ATI driver which only exposes 24bit visuals.  With this extension
we might be able to get a real 16bit visual.  The latest nVidia and ATI drivers
both support the FBO extension.

Regards,
  Aric