Sign in to follow this  
Jengu

glCopyTexImage2D doesn't work with covered windows :(

Recommended Posts

I'm using glCopyTexImage2D for rendering to texture because it is the most compatible option. I want to run on old cards, so FBOs aren't an option, and pbuffers are a pain because they have to be recoded for every platform. The problem is that I'm rendering in a window rather than full screen. If the user drags the window so that part of it is off screen, glCopyTexImage2D gets black pixels for a large area of the texture, because those pixels were offscreen when the scene was rendered. Is there some workaround for this? Can I tell windows to fill in those pixels even though they're offscreen? Strangely I only get this behavior under XP, everything works fine on Vista @_@

Share this post


Link to post
Share on other sites
This is because of what's known as the Pixel Ownership Test (the first per-fragment test in the OpenGL pipeline). It tests if the pixel that corresponds to the current fragment's window position belongs to the current GL context or not. If the fragment fails this test then what happens to the fragment is window-system-dependent. Apparently Windows Vista lets the fragment continue down the pipeline (that's news to me, interesting).

The workaround you are looking for is to render into an offscreen buffer, which will be completely owned by the GL context. You already mentioned the two options you have for this, FBOs or Pbuffers. I don't think there's anything else you can do about it.

Share this post


Link to post
Share on other sites
Damn, just to be sure I'm going to code up an example using GLUT to make sure it's not some weirdness with wxwidgets (my windowing toolkit). The only workaround I can think of (without changing to FBOs or pbuffers) is figuring out how much of the window is visible, and then using the visible window area to do tiled rendering. I wonder if Vista lets it continue down the pipeline for technical reasons related to Aero/compositing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jengu
I wonder if Vista lets it continue down the pipeline for technical reasons related to Aero/compositing.


Correct; unlike with previous versions of windows each window in Vista gets it's own chunk of memory to render into, as such you can't fail the pixel ownership test because you always own all the pixels you are rendering to.

Share this post


Link to post
Share on other sites
Crud, I have myself in a bit of a bind then:

1. wxWidgets won't easily work with pbuffers because they are windows specific and use HWND window handles
2. FBOs aren't an option because older cards don't support them
3. glCopyTexImage2D doesn't work all of the time

I guess I'll have to try to hack pbuffers into working with wxWidgets. This is going to be nasty :P

Share this post


Link to post
Share on other sites
Actually, if it's the pixel ownership test that's the problem, then how do pbuffers work? Since they're never visible wouldn't they also fail the ownership test?

Share this post


Link to post
Share on other sites
I use the same method, for the same reason. I'm on XP and it works fine with me. Have cube mapping and shadow map, and everything seems to be fine when I drag most of the window offscreen.

Possible influence factors:
1) Drivers (I'm on latest Catalyst, ATi X800)
2) Rendering context (I'm rendering on an MFC button)
3) Window properties (OWNDC maybe?)

I guess pbuffers are always owned by you (visibility doesn't count for them), that's why they always work.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Quote:
Original post by Jengu
I wonder if Vista lets it continue down the pipeline for technical reasons related to Aero/compositing.

Correct; unlike with previous versions of windows each window in Vista gets it's own chunk of memory to render into, as such you can't fail the pixel ownership test because you always own all the pixels you are rendering to.

And this is also the case on Mac OS X - it is the basis that allows all the fancy OpenGL-accelerated GUI effects.

Quote:
Original post by Jengu
Actually, if it's the pixel ownership test that's the problem, then how do pbuffers work? Since they're never visible wouldn't they also fail the ownership test?

If that was true, pbuffers would be useless, as no pixels would ever be affected by rendering [smile]
The pixel ownership test should only apply to contexts rendering into on-screen windows.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jengu
Actually, if it's the pixel ownership test that's the problem, then how do pbuffers work? Since they're never visible wouldn't they also fail the ownership test?

The pixel ownership test is not a visibility test. It is, as the name implies, an ownership test; it's a test whether the rendering context owns the pixel being rendered.

An overlapped pixels may or may not be owned by the rendering context. An offscreen buffer is exclusive to the rendering context and so will always pass the ownership test becuase no other device can own that pixel under any circumstances. It's not about visibility, but about ownership.

Share this post


Link to post
Share on other sites
Just to make sure I understand -- XP allocates a block of VRAM the size of the screen (* color depth) to serve as the framebuffer. Then each window, depending on its position, is allowed to "own" rectangular chunks of the framebuffer. If a window is partially offscreen, XP doesn't let the window own the offscreen pixels. Correct?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this