Sorry that I have to start anyother thread since my previous thread was hijacked. It got too long.
Korval, your points are well taken. I should have to rely only on defined behavior. Who to blame? I blame the spec which allows undefined behavior, which leads inconsistency.
Humus, thanks for swap behavior info about ATI, I haven’t thought about all those cases. Basically, they are inconsistent among themselves. I do like your view on pixel ownership test. I think the test should only affect the front buffer, the back buffer would be guaranteed to be updated because that’s the way how people think.
It’s very frustrating to see a solution developed on one openGL driver doesn’t work as expected on another driver.
swap behavior or pixel ownership test aren’t the few isolated cases. I see a pattern. pbuffer is another example. I developed my pbuffer solution on Nvidia. It seems working fine, but when tested on ATI or Intel, it doesn’t work.
1). I can’t successfully create pbuffer on Intel card even thought it lists ‘WGL_ARB_pbuffer’ as supported extension and it passes wglChoosePixelFormatARB() test. I have to spend more time to look into why.
2). ATI doesn’t support ‘WGL_NV_render_texture_rectangle’ extension on PBuffer even though it supports GL_EXT_texture_rectangle on main buffers.
3). Why does PBuffer have to be power of two, why can’t it be like any other buffer. I am creating a backing store for a openGL window, since my window can be obscured or off-screen, I no longer can rely on the back buffer to capture the content of my window. So I use pbuffer. If I have a 1600x1200 window, I end up creating pbufer of 2048x2048, very wasteful of vmem. The same thing is true to texture. Since ATI doesn’t support NPOTD texture in pbuffer, so my texture ends up just like pbuffer 2048x2048. I often end up having unpredictable behavior due to running-out-vmem.
In the end, my pbuffer solution only works on Nvidia.