Does anybody know why glCopyPixels on some hardware is very slow. I use glCopyPixels to update parts of the screen (e.g. for menu’s).
With the Microsoft generic OpenGL implementation this is very fast.
The menu is drawn in the back buffer and copied to the front buffer with the following code:
With the ‘Microsoft GDI generic V.1.1.0’ OpenGL implementation this is very fast. With the ‘NVIDIA GeForce2 GTS V1.2.1’ implementation it is also very fast. With the ‘NVIDIA RIVA TNT V1.1.0’ you can already see a drawing delay. With the ‘ATI RAGE PRO V1.1.0 Win95 ICD’ it is very slow, when the Microsoft GDI generic implementation is used on the ATI hardware it is very fast.
How can I get realtime partial updates of the screen in OpenGL that works on all hardware.
A faster method might be to upload the image as a texture, and draw it on the screen using a quad. But this isn’t quarateed to work fast either. If you want a method that works, you can use glDrawPixels, even though it might be slow, it will still work.
It’s possible to explain the speed difference, but that won’t solve your problem. A “hardware” implementation would be slow if it’s done in software (which may be due to hardware limitations or the driver writers not getting to optimise that operation). A naive implementation would use ReadPixels/DrawPixels, which would be very slow, and perhaps what the Rage Pro is doing.
Back to your problem - I’d like to know what you’re doing, exactly. You say that you’re drawing the menu into the back buffer, and copying to the front buffer, and what I don’t understand is why you’re not just drawing the menu directly over the graphics.
the fact that running a thing similar to this on my voodoo2… made the fps drop to like 5 fps… but if it used the windows generic driver it went at the nice 60 fps…
so how can that mix of software and hardware be so much slower then when using pure software??
ET3D I render the menu’s, buttons, sliders etc in the back buffer first because the background of this controls is rendered first and then the images and text is rendered. Drawing directly to the front buffer results in flashing of the images and text.
Can’t you just do a buffer swap instead? CopyPixels i srarely used and therefore you can’t count on performance, driver writers might be too lazy to implement it so it runs fast enough.
A buffer swap is possible if the back buffer containes the same color pixels as the front buffer. This means I first have to copy the complete front buffer to the back buffer which is even slower. Or do you have a solution for this ?
What exactly is it you need from the front buffer? Can’t you just first render whatever you render into the back buffer normally, then render the menus on top of that (into the back buffer as well) and then do the buffer swap? If you wan’t to avoid updating the entire screen you can check out the swap hint extension.
The first time the pop-up menu is rendered it is indeed rendered on top of 3D scene followed by a buffer swap. When the mouse pointer moves over the menu only the menu is updated.
You can download my free modeler to see what I mean: www.microcan.nl.
If the swap hint extension is supported by all hardware this is a good option but I prefer a generic option.
ET3D is right, the buffer region extension is what you’re after, it avoids redoing the 3d rendering to update 2d stuff. I’d give you a link to the spec in the extension registry but the server seems to be down.
[This message has been edited by harsman (edited 05-29-2001).]