Jump to content
  • Advertisement
Sign in to follow this  
SasQ

D3D windowed - obscured window problem

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. API: DirectX 8 + Win32. System: Win2000 Prof. I'm launching DirectX in a window [not fullscreen]. I'm only clearing viewport by random color, not rendering anything special. If I obscure only a part of a DX window by another window, nothing happens too, everything goes fine. But when the DX window is obscured totally, strange things are happening. All system starts to slow down, even a mouse is getting a hick-up :P I have looked to Task Manager - the process with DX window takes only 2% CPU time, but obscuring window's process takes 99% CPU power! :| I don't know why that happens, because it's rather plain code, like in many tutorials on the net. The message loop:
MSG msg;
while (1) {
  if (PeekMessage(&msg,0,0,0,PM_REMOVE)) {
    if (msg.Message==WM_QUIT) break;
    TranslateMessage(&msg);  DispatchMessage(&msg);
  } else {
    Render();
  }
}

Render() function is only that:
pD3DDev->Clear(0,0,D3DCLEAR_TARGET,rand(),0,0);
pD3DDev->Present(0,0,0,0);

My DX initialization:
pD3D = Direct3DCreate8(D3D_SDK_VERSION);
if (!pD3D) return false;

D3DPRESENT_PARAMETERS pp;  ZeroMemory(&pp,sizeof(pp));
pp.Windowed         = true;
pp.SwapEffect       = D3DSWAPEFFECT_COPY_VSYNC;
pp.BackBufferFormat = D3DFMT_X8R8G8B8;
if (FAILED(pD3D->CreateDevice(D3DADAPTER_DEFAULT,D3DDEVTYPE_HAL,hOkno,
                    D3DCREATE_SOFTWARE_VERTEXPROCESSING,&pp,&pD3DDev)))
{
 FreeDX();
 return false;
}

I set that SwapEffect because i thaught that message loop "rotates" too fast when it isn't anything to render. Earlier was D3DSWAPEFFECT_DISCARD. But SwapEffect change doesn't help ;P Ant this is my code wchich makes a window:
WNDCLASSEX wcx;
wcx.cbSize        = sizeof(wcx);
wcx.hInstance     = hProgram;
wcx.lpszClassName = szClassName;
wcx.lpfnWndProc   = WindowProc;
wcx.style         = CS_HREDRAW|CS_VREDRAW;
wcx.hbrBackground = (HBRUSH) GetStockObject(LTGRAY_BRUSH);
wcx.hIcon         = LoadIcon(0,IDI_APPLICATION);
wcx.hIconSm       = LoadIcon(0,IDI_WINLOGO);
wcx.hCursor       = LoadCursor(0,IDC_ARROW);
wcx.lpszMenuName  = 0;
wcx.cbClsExtra    = 0;
wcx.cbWndExtra    = 0;
RegisterClassEx(&wcx);

hwndMain = CreateWindowEx(0,szClassName,Title,WS_OVERLAPPEDWINDOW,
                         CW_USEDEFAULT,CW_USEDEFAULT,400,300,
                         0,0,hProgram,0);

Anyone has any idea what makes that irrational working? :/ [Edited by - SasQ on May 21, 2005 11:37:53 AM]

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by D a n o
try, BeginScene() and EndScene()


I can't imagine that helping since he doesn't render anything.

Can you post the workspace? I'd like to try it on my machine.

Matt Hughson

Share this post


Link to post
Share on other sites
Or try this:
while (PeekMessage(&msg,0,0,0,PM_REMOVE)) {
if (msg.Message==WM_QUIT){
exitMyApp();
break;
};
TranslateMessage(&msg); DispatchMessage(&msg);
};

Share this post


Link to post
Share on other sites
Scene and quitting the app is not my problem :P
Did you at least read what i wrote? -_-

The most strange is that NOT the DX app slows down the comp, but the one which obscures totally DX window :|

I may post my source if necessary, but code is plain and tendentious, like in any DX8 tutorial on the net. Take any of these tutorials and you'll see the same effects. Looks like M$ is giving us a booby-trap ;D

Share this post


Link to post
Share on other sites
Quote:
Original post by SasQ
Scene and quitting the app is not my problem :P
Did you at least read what i wrote? -_-

The most strange is that NOT the DX app slows down the comp, but the one which obscures totally DX window :|

I may post my source if necessary, but code is plain and tendentious, like in any DX8 tutorial on the net. Take any of these tutorials and you'll see the same effects. Looks like M$ is giving us a booby-trap ;D


I can't repro this on my laptop with the "Textures" tutorial. The behavior I get is that when non obscured, Textures.exe takes ~9% CPU. When totally obscured by Internet Explorer, Textures.exe takes ~100% of the CPU (mouse and what not seem fine eithe way).

This is somewhat expected for the tutorials as they do not attempt to detect when the app is inactive and avoid rendering. Instead they render, but since they are obscured, the rendering takes no time and the app "immediately" goes back and peeks more messages. Basically, the result is a tight message pump that is doing very little actual work and instead is spin waiting. Spin waits will take 100% of the CPU pretty quickly.

The tutorials don't do alot of the stuff that applications should do to behave nicely on Windows. DXUT does handle alot of these situations so you'll note that the samples (which use DXUT) do not display this behavior.

Paul

Share this post


Link to post
Share on other sites
Quote:
Original post by paulble
Quote:
Original post by SasQ
Scene and quitting the app is not my problem :P
Did you at least read what i wrote? -_-

The most strange is that NOT the DX app slows down the comp, but the one which obscures totally DX window :|

I may post my source if necessary, but code is plain and tendentious, like in any DX8 tutorial on the net. Take any of these tutorials and you'll see the same effects. Looks like M$ is giving us a booby-trap ;D


I can't repro this on my laptop with the "Textures" tutorial. The behavior I get is that when non obscured, Textures.exe takes ~9% CPU. When totally obscured by Internet Explorer, Textures.exe takes ~100% of the CPU (mouse and what not seem fine eithe way).

This is somewhat expected for the tutorials as they do not attempt to detect when the app is inactive and avoid rendering. Instead they render, but since they are obscured, the rendering takes no time and the app "immediately" goes back and peeks more messages. Basically, the result is a tight message pump that is doing very little actual work and instead is spin waiting. Spin waits will take 100% of the CPU pretty quickly.

The tutorials don't do alot of the stuff that applications should do to behave nicely on Windows. DXUT does handle alot of these situations so you'll note that the samples (which use DXUT) do not display this behavior.

Paul


I just noticed you are using dx8 and win2k, so it is likely that dx8 and dx9 differ with respect to window manager integration. I don't have a win2k machine handy so I can't readily repro this.

Paul

Share this post


Link to post
Share on other sites
Quote:
Original post by paulble
This is somewhat expected for the tutorials as they do not attempt to detect when the app is inactive and avoid rendering.


Sometimes it is also expected from real apps, when you watch some animation in one window [inactive] on the left, and you e.g. write something in another window [active] on the right.

Quote:
Original post by paulble
Instead they render, but since they are obscured, the rendering takes no time and the app "immediately" goes back and peeks more messages. Basically, the result is a tight message pump that is doing very little actual work and instead is spin waiting. Spin waits will take 100% of the CPU pretty quickly.


I checked this too. I have left Render() function empty, without any DX calls. If it were that way like you said, the app should now slow down too. But it didn't :| It takes 99% CPU, but the system behaves normal, nothing slows down.

When I add Present() in the main loop, still everything is OK. But when i add Clear(), slowing down appears again.

I think there is something strange with messages sent by Windows to the topmost window obscuring DX window. Maybe some redraws, but I don't know, even how to "debug" it :/

OK here is my code [DevC++ 4 project, but the CPP is "universal" ;) ]:
http://www.wsi.edu.pl/~sistudem/DX8.zip

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!