First: I've not tried it myself.

On WM_MOVE, you might try checking the window position against the desktop size to see if a portion of the client window is hidden. Change your viewport to render only what's visible. That may not help if Windows thinks the entire client rect is dirty.

You might try the above with the addition of setting the "dirty" rectangle to just what's visible.

Another thing to try: make sure your swapchain is created with D3DSWAPEFFECT_COPY and make sure your Present rect parameters reflect only the visible portion of the client rect.

Quote:i don't have a fluid motion

Are your updates based on seconds-per-frame each frame? If they're based on a fixed interval (an assumption that you're always getting 16mS per frame), you might want to change that. If you're going to do that, use a precision timer. Your mention of 16.667 and 35, etc., implies you're using timeGetTime perhaps and not the precision timer (QueryPerformanceFrequency and QueryPerformanceCounter).

Quote:I'm using the D3DSWAPEFFECT_DISCARD flag instead of COPY and I call the Present with the statement device->Present(NULL, NULL, NULL, NULL) so the entire surface is always presented. Is it incorrect?

It's not incorrect if you always want to present the entire buffer (see the docs for IDirect3DDevice9::Present).

For the specific problem you're talking about, with a portion of the client outside the desktop, I thought perhaps it might be solved by presenting only a portion of the buffer. To do that, you'd need to use _COPY and add specific rectangles to the Present call.

Quote:The time function is timeGetTime() with timeBeginPeriod(1) and timeEndPeriod(1) with a precision of 1ms. Is it better to have a more accurate timer?

I agree that the docs claim a precision of 1ms. My experience (and a bit of googling on the subject) indicates that the actual "precision" depends on the machine and OS. Something like 10-15ms is probably a better assumption. If you choose to update based on actual seconds-per-frame rather than a fixed interval, you might want to consider using the performance counter rather than the system timer. Or, do some testing of the system timer and see if you're actually getting the precision you're assuming.

However, if you're using a fixed interval for updating, then the question is moot, right? Also, it sounds like you're updating 25 times per second (each 40ms) and "rendering is done as fast as possibile." You might consider D3DPRESENT_INTERVAL_IMMEDIATE and avoid the (slight) overhead. Be sure to check the devcaps to see what intervals are supported. I don't imagine that INTERVAL_ONE is not supported but you never know.

[WINK]If you believe the 1ms claim, then you shouldn't be relying on values like 16.6667. Maybe 16+/-1?

http://msdn.microsoft.com/en-us/library/ee416646(VS.85).aspx

D3DSWAPEFFECT_COPY has nothing to do with your problem. It makes Present call only slower.
Also, this "problem" is not something you should fix. It doesn't kill your PC, it doesn't make normal users enjoy the game less (after all, it will be runned in fullscreen mode, right?). You should change the window startup position to the center of screen instead.

My guess this is a limitation from your driver/video card.
You should try another system with a different video card, Intel's are usually pretty crap. May be you have luck on the Intel forums

I wouldn't be surprised if your driver, internally, falls back to COPY instead of DISCARD when the windows is partially outside the screen because the card can't handle it. That could explain it.
When you try COPY (all the time), does it slowdown in the same way, but only this time not only when the windows is out of the screen, but rather all the time?
Copying takes a lot more time than flipping a buffer, and the time it needs grows geometrically with the window resolution (unlike flipping/discard, which needs constant time and is very low). When you use VSync with Copy, the system will wait for the refresh, but due to the amount of time needed for the copy it may take more time, and still idle wait more than it should, slowing your frame rate.

Anyway, welcome to the windowed mode world!
In windowed mode, this stuff tends to happen (specially in WinXP). For example, my game (and all of them) experiences a similar slowdown when a MSN Messenger notification icon or similar appears in front of my app window, and I'm using a dedicated NVIDIA GPU!

Just being curious, your game isn't multithreaded, is it?
Because I've had the exact same problem due to some multithreading issues in my game engine when VSync was enabled (which I fixed by not messing up with SetThreadIdealProcessor, and disabling a console I was creating using AllocConsole and hooking stdio to it; yeah... I don't know how this is related to VSync, but it was causing trouble somehow when vsync was enabled)

Cheers
Dark Sylinc

Quote:but i think it's not pretty to prevent the user to drag the window wherever he wants

I'm not saying that you should prevent that. I'm just saying that you should not waste your time fixing things that 99.99% of the players will not notice..
EDIT:

Quote:Reading the doc at http://msdn.microsoft.com/en-us/library/ee416646(VS.85).aspx
it seems to me that with the D3DSWAPEFFECT_DISCARD flag i can only use NULL and cannot define a source rect for the Present method so i must swap the entire surface, even the portion not visible because outside the screen area. Am i wrong?

You don't need to define it if you're not looking for some special effects. No one ever draws something that is outside of any surface. You just don't have a destination pixel there... :)