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