I will admit this is a problem I have had for a while and never fixed. I figure its about time I learn what is going on. When I create a window and setup a directX device all is well. The window shows up and is rendered how I want it. The problem occures when I move the window around with my mouse. As I drag the window and part of it goes off of screen it turns white when I pull back into view. This happens until I let go of the mouse. When the mouse is let go the window redraws itself. Looking through the DirectX sample this is not a problem. So, what am I missing? Regards Chad

When your window is being dragged, your message pump will go into a modal loop and none of your code will get a chance to execute unless you respond to WM_MOVING notifications or WM_PAINT notifications. I believe the samples will render upon receiving WM_PAINT, which causes them to re-draw when the off-screen portion of the window gets invalidated.

I think I get what your saying but I am not sure the best way to do it. So i have a few question...

1) Lets say this is a snippet of my game loop where I deal with messages
Should I send the message to a custom funtion that will check it for WM_PAINT. And then do something along the lines of..


Does this wound about correct? If not do you have any suggetions? One thing that I am thinking of is that it might not be the most efficent way. Considering my WindowProc is already checking the messages I feel weird about making another check outside of it. Truth be told I don't know if this is a warrented thought. As far as I know this is the only way to do it.

Regards

ChaD

What exactly are you after, do you just want the rendered window content to be visible when you move the window (but a static image), or do you want the game to keep going and updating (animations etc)?
Is it just when you move the window, or do you want it when you resize?
If so, is it enough that the current image is scaled, or do you want to re-render at the new resolution as the user is resizing?

The easiest might be to use copying instead of swapping to Present the back-buffer. Then you can just call Present again in WM_PAINT. I guess that the samples do something like this, as with resizing nothing is re-rendered at the new resolution until you are done resizing, it's just a scaled static image. I'm not sure exactly the method they use, there are multiple ways to do it. I would look through the code the SDK samples use.

Quote: Original post by Erik Rufelt
What exactly are you after, do you just want the rendered window content to be visible when you move the window (but a static image), or do you want the game to keep going and updating (animations etc)?
Is it just when you move the window, or do you want it when you resize?
If so, is it enough that the current image is scaled, or do you want to re-render at the new resolution as the user is resizing?

The easiest might be to use copying instead of swapping to Present the back-buffer. Then you can just call Present again in WM_PAINT. I guess that the samples do something like this, as with resizing nothing is re-rendered at the new resolution until you are done resizing, it's just a scaled static image. I'm not sure exactly the method they use, there are multiple ways to do it. I would look through the code the SDK samples use.

1) I am not giving the user an option to resize.
2) Because the user does not have the option then scalling or rendering is not an issue at this point.
3) As the window is moving I just want a static image.
4) When the user release the window it should start its normal render cycle.

Looking at the simplest of DirectX samples they simply make a call to there "Render" function when WM_PAINT is recived. My issue is that my "Render" function is a part of a class object. Which leads me to another question that I just posted in the beginners section.

Question

How do you acceess "Render" in side the message handeler when render is a part of a class object?

Regards

Chad

Was a thread like this a while back.. The solution they came up with was to stop repainting the window.
So that it doesnt get black edges etc if temporarily overlapped.

A search could probably reveal it :)

Quote: Original post by marius1930
Was a thread like this a while back.. The solution they came up with was to stop repainting the window.
So that it doesnt get black edges etc if temporarily overlapped.

A search could probably reveal it :)

Do you have any suggestion for keywords to search for. I have been searching for the past few hours and have not found anything.

REgards

Chad

you could stop using WM_PAINT

Quote: Original post by eFoDay
you could stop using WM_PAINT

Care to expalin some more? I was not using WM_PAINT until it was suggested to me by the first responder. At this point if I don't check WM_PAINT how will I know if the window is being invalidated?

Regards

Chad

Last time I used WM_PAINT was with GDI because it was so slow you had to make "dirty" regions and only update that area or there would be tearing.

Direct3D is fast and you can redraw the entire screen as fast as possible so your render function can just go in the main loop.

Oh and I see its only going white when you take it off screen. I thought it was going all white when you just moved it.

When I move my window off screen then back on it shows like the edge of the window or something until you let go of the mouse. So I guess you would have to do something else.