Mysterious frame buffer stuff

Hi,
I have a problem. I have created a routing to copy an image to the front and the back buffer. I display it. I use it as a loading screen. I also created a loading bar. Simply overwrite a portion of the image.

I works well, except one thing. During the loading process the screen flashes. The picture is erased somehow. But I do not clear the buffers.

The main problem is that I must do it in this way. So the create textures from that picture and produce quads to cover my screen is not usable for me.

Does anyone has an idea?

Although I have not experienced this, I have heard people say that this can happen if you dont respond to Windows’ WM_PAINT messages properly. I guess after the message sits there long enough, Windows just erases your app window automatically.

Is this an MFC app? If so, be sure you override OnEraseBkgnd(…).

This is not an mfc program. The WM_PAINT could be a reason, but when handle that the program freezes. Any ideas? I have a tnt2 with the newest detonator.

You need to handle WM_PAINT.

Your immediate reaction should be
“why does my program freeze?”

Are you using multiple threads? If so, which
one is creating the GL context? Are you
properly activating the context? Is WM_PAINT
called before the context is created?

Originally posted by bgl:
[b]You need to handle WM_PAINT.

Your immediate reaction should be
“why does my program freeze?”

Are you using multiple threads? If so, which
one is creating the GL context? Are you
properly activating the context? Is WM_PAINT
called before the context is created?[/b]

Thaks guys.
The app freezes after 2-3 frames. Yes, I am using multiple threads, but the gl context is created and owned by the same that creates the window, the others are network communication, mp3 player. Except this bug the whole thing runs well on various 3d hw. When I simply create a “case WM_PAINT” in the message handler loop and return zero, after those 2-3 frames the program locks up. It is really strange. I miss something, but I do not know what.

It’s me again. I eliminated the freeze bug (it was in the message handler loop), but I still can’t do anything with the mysterious frame buffer clearing.

here’s how I handle the messages:

case WM_ERASEBKGND:
return 1;

case WM_PAINT:
hdc=BeginPaint(hWnd,&ps);
EndPaint(hWnd,&ps);
return 0;

What else could I do?

This certainly won’t be of much help, as I don’t have my sources here, but …

I think in my switch case, for the WM_PAINT message, I have something like :

case WM_PAINT:
break; /* and then return something */

but I don’t remember calling BeginPaint at all… It wouldn’t surprise me that with this call, Win tries to ‘do’ something to your window that is not nice…

I’ll check my handling of WM_PAINT !

If, when you created your WindowClass, you loaded a brush, such as

WindowClass.hbrBackground = (HBRUSH)GetStockObject( BLACK_BRUSH );

then every time you call the beginpaint/endpaint spiel, it’s going to erase your background

my 2 ways around it are
1)

WindowClass.hbrBackground = 0;

or 2) (Thx to Andre Lamothe)

case WM_PAINT:
    InvalidateRect( hWnd,0,false );
    GlobalDisplay( );
    ValidateRect( hWnd,0 );
    return 0;

hope i’m right and this helps

[This message has been edited by Succinct (edited 11-15-2000).]

Thanks.

I belive the solution lies between these two.

Csaba