Some times, when my main opengl window grows up ( for instance, when one controlbar is going to be undocked from the mainframe ) the system lose the hardware acceleration.
It also appears when the window is resized, bigger than his initial state.
I relly don’t know how to play with this bug …
The availability of hardware acceleration on this TNT2 based board with OpenGL in a window depends on the amount of onboard memory and the size of the window.
The driver is clever enough to support hardware acceleration as long s there is enough memory available for the back and z-buffer.
If you have a 16 MB board and use a big truecolor resolution, calculate the following to see if a fullscreen window will have HW acceleration: xresyres3 buffer4 bytes. If you end up with with something near the onboard memory size of above, you will run into software fallback mode, which is probably slower than choosing a MS GDI Generic pixelformat because drawing into the onboard video ram with the CPU is slower than into the host’s memory and blitting mem-to-screen.
Example: 1600120034 is about 22 MB. So a fullscreen window would not work in HW. But let’s say a window with 1024*768 still has HW acceleration on that screen. But not a second one of that size…
Thanks for the answer,
Do you know how I can get prevent for a such memory overhead ?
My soft is using a lot of texture mapping, so a such swich to software emulation seems to lock the application !
Is it possible to get the amount of used memory or the amount of free space available for drawing ?
Unfortunately I’m not aware of any method to get this information from the driver. In case of a software fallback the texture management seems to give up. Have you tried a different/newer driver?