We are experiencing a very annoying OpenGL rendering put which seems to only happen on the MacOS X Panther (10.3) platform. My feeling is that it is a driver or Apple bug but I’m not sure how to get it to the right people. I have put some images which show the problem along with an executable and source code at: http://www.ivs3d.com/applebug for anyone interested in checking it out.
The core problem seems to be if you change from normal double buffering (rendering in the back buffer then swapping to front) to front buffer rendering by issuing the glDrawBuffer( GL_FRONT ) command. When you do this on an affected machine you will get a bunch of garbage in the background of the application window. To demonstrate this we created a little application that draws a sphere. When you hold down the mouse button the sphere is rendered with the usual animation loop (Draw in backbuffer, swap buffers, repeat). When you let go of the button it switches to front buffer rendering and draws the sphere at a much higher resolution.
Normally this problem manifests itself when running on the external head of an apple laptop (or when connected to a projector). Usually the main laptop display works fine but the external display is corrupted.
Any ideas or suggestions would be greatly appreciated.
We had a somewhat similar problem – glReadBuffer(GL_FRONT); glReadPixels(…); produced garbage.
The response we received from Apple was that the OpenGL spec says that the results of reading from the front buffer are undefined for parts of the front buffer that are occluded. Since on Mac OS X there is no way to determine which parts of the front buffer are occluded, the window system / renderer makes the (valid, but unhelpful) assumption that the entire buffer is occluded.
That’s the justification under the spec… I suspect that the real reason is technical.
<speculation>
I don’t know, but I think the front buffer of the context is owned by the window manager, probably shared write-only with the application for security reasons.
</speculation>
I suspect the same holds for rendering to the front buffer…
If you go full-screen, I think you’ll find you have full access to both buffers.
I can see what you’re saying but in this case we are not reading but writing and this is definitely part of the OpenGL spec. and is therefore a bug (IMO).
<mySepeculationNow>
What appears to be happening is that on a glDrawBuffer(GL_FRONT) apple is actually allocating a new buffer and not directly pointing to the real existing one. In this new buffer any part of it that did not have geometry drawn now contains garbage. Any part of the window that contained geometry before the glDrawBuffer(GL_FONT) is called seems good.
</mySepeculationNow>
It’s also suspicious that it worked fine in OS 10.2 but not in OS 10.3 with it “Improved” ATI graphics drivers.
Going full screen is ok if your just taking over the screen for rendering but won’t work for a full blown professional scientific visualization application (with lots of user interface components). I think I’ll have to register as an official Apple developer so I get the right to pester them.
“What I don’t understand is why you’d ever /want/ to render to the front buffer…”
Ahh… well you can do some very nice rendering tricks. In our case for example we want to render far more data then can be rendered interactively. Thus a person navigates interactively to a particular scene location then he/she stops and the scene renders in full detail. Lets say this full detail takes 10 seconds to complete - asking a user to wait that time while the scene renders in the background is like waiting forever. However if you carefully render it in the foreground then many times the area of interest is filled in much less time even if the overall scene still takes 10 secs and the user feels that things are much faster. The whole process is fairly complicated but it works very well - except on the Mac…
