I was wondering if anybody have this problem and how it can be solved:
Environment:
When in a SDI window with OpenGL running in a child thread. A model of hug polygon count (about 1000000 tri-polygons) with < 100% opacity is loaded in the view window.
Problem:
When one resizes the window, a strange grey color was drawn into the view before it is displayed completely. In some cases, parts of the model showed up in the grey area. glFinish before SwapBuffers does not rectify the problem.
Suspicion:
I suspect I have hit a performance bottleneck in the OGL pipeline. If so, what is the likely workaround?
Originally posted by JHChong:
[b]I was wondering if anybody have this problem and how it can be solved:
Environment:
When in a SDI window with OpenGL running in a child thread. A model of hug polygon count (about 1000000 tri-polygons) with < 100% opacity is loaded in the view window.
Problem:
When one resizes the window, a strange grey color was drawn into the view before it is displayed completely. In some cases, parts of the model showed up in the grey area. glFinish before SwapBuffers does not rectify the problem.
Suspicion:
I suspect I have hit a performance bottleneck in the OGL pipeline. If so, what is the likely workaround?
I would appreciate any input.
Thank you,
Chong[/b]
I have the same effect, but I think that’s normal.
When you resize the window, the size of the buffer is also changing (I am talking about backbuffer also!!!).
What sould the driver do? Scale the old image? No, it simply clears the buffer with gray color (and clear the Z-buffer, etc.), and continue the rendering.
So what do you see after buffer changing? A picture with gray background and the second half of your rendering commands…
Of course it’s a workaround that you see before the bufferswap whether the window size is changed while you rendered the image.
If yes then you shouldn’t swap the buffer, just start the rendering again.
Sounds to me like it could be Windows erasing the background. Make sure the hbrBackground member of your window class is null or intercept the WM_ERASEBACKGROUND message and simply return null.
Originally posted by Madoc: Sounds to me like it could be Windows erasing the background. Make sure the hbrBackground member of your window class is null or intercept the WM_ERASEBACKGROUND message and simply return null.
Doesn’t help. I have seen some demos and all do this deffect.
Originally posted by M/\dm/
: It will be there until you’ll draw your frame, & in your case I guess FPS are verry low.
No. I render in a different thread with 130fps, but when I resize the window quite slowly (hold button, slow mouse moving), I get a nice gray window…
All program I know (DirectX: same with white color) do this.
And therein lies the problem. You’re doing your rendering in a different thread from the actual window.
When the window is resized, it received a WM_PAINT message. This is Win32 telling the window to redraw itself. Unfortunately, you don’t do any rendering in WM_PAINT. Since the buffers have been destroyed and re-created, precisely what lives in that memory is fully driver/API dependent.
Also, it is entirely possible that, in the middle of rendering, the user could be resizing the view. Had you been rendering in the WM_PAINT handler, there wouldn’t be a problem (because the window itself doesn’t get resized until it receives various sizing messages). This, of course, means that the graphics API will interrupt your rendering with a buffer-resize operation. This will, likely, clear the buffer, thus destroying what was there.
The best you can hope to get is to just clear your buffers before you render your scene.