Re: CPU performance rises when I'm opening an other application/dialog



"Michael Schwab" <MichaelSchwab@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:787E3F70-321F-4565-A303-2FCB0856CDFE@xxxxxxxxxxxxxxxx
> Goodness those other "answers" were about as half baked as you can get.
> I've
> seen the exact same problem you're experiencing and have a templated
> solution
> I use on each app now. Consider the following game loop...

Most of my work is in unmanaged C++, and I've not quite wrapped my head
around finding the optimized game loop yet for managed code, but I think I
have a few suggestions that might be of use...

> while (form.Created)
> {
> if (form.WindowState != FormWindowState.Minimized)
> {
> //Update our game, and render to screen
> form.Render();
> Thread.Sleep(1);
> }
> else
> {
> Thread.Sleep(300);
> }
> Application.DoEvents(); //Let the OS handle what it needs to
> }

Another useful thing to check is if the form is currently activated, by
trapping form activation and de-activation. This can allow you to stop
animation when the form is not in the foreground, and only call your Render
function when a Paint event is received. This allows the form to properly
redraw without taking up CPU time with ongoing animation when another
application or form has the focus. Another option would be to use a longer
Sleep interval while the form is not activated, to throttle back the frame
rate and give more processing time to other applications.

> form is my directx window. form.Render() calls a bunch of objects that
> know
> how to render themselves. The interseting part is the Thread.Sleep(1)
> line.
> This little sleep period causes the app to release system resources and
> cut
> my "background mode" cpu utililization from +80% to < 1%.

Another interesting use of Thread.Sleep() is to pass it a value of zero.
This allows the thread to yield to other pending threads, or returns
immediately if there are none pending. This can allow an un-throttled
rendering loop to gracefully concede time to other threads, and help prevent
pre-emptive context switches that can hurt your rendering performance as
well.

> In a real app. You'd likely have a variable whose value changes based on
> the actual render time of your app, this would become your fps lock if you
> wanted to lock your fps to 60fps or whatever.

Usually it's preferable to lock the presentation interval to the vertical
refresh. To prevent time from being taken up while Device.Present waits for
the device, use SwapChain.Present with the Present.DoNotWait flag and call
Sleep(0) while this function throws a WasStillDrawingException.

> Either way, without the
> sleep, you're app will run as fast as possible and utilize as much cpu as
> is
> available (why this only happens when the app is in background mode,
> is still a mystery to me).

That is an interesting pattern. A DirectX application can often utilize
high CPU when it's in the foreground, but if well mannered its usage should
drop when other applications take the foreground.

I'd be curious to take a look at what's occurring here... do the managed DX
samples show this behavior?
--
Robert Dunlop
The X-Zone
http://www.directxzone.com/
Microsoft DirectX MVP
-------------
The opinions expressed in this message are my own personal views and do not
reflect the official views of the Microsoft Corporation.
The MVP program does not constitute employment or contractual obligation
with Microsoft.


.



Relevant Pages

  • Re: CPU performance rises when Im opening an other application/dialog
    ... The way the sample framework does it has changed several times and is about ... > not reflect the official views of the Microsoft Corporation. ... >>> I use on each app now. ... >> Render function when a Paint event is received. ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: CPU performance rises when Im opening an other application/dialog
    ... reflect the official views of the Microsoft Corporation. ... >> I use on each app now. ... > Render function when a Paint event is received. ... > Microsoft DirectX MVP ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: VS IDE Blues
    ... > keyboard waiting for pages to render that I don't even want rendered! ... development in a similar way to how it will run in production. ... > leaving .net for Java is all the marketing drivel inserted in the Microsoft ...
    (microsoft.public.dotnet.general)
  • Re: Unhandled crash repost - as the server bombed when first posted.
    ... As to Microsoft not monitoring this newsgroup, then why is it hosted by Microsoft and called a Microsoft newsgroup:-O. ... Thanks again though Paul - yes we have spoken on this one in the past, so please accept my apologies if you had indeed already told me this. ... In reality - as it often appears not to be detrimental to the operation of my own app, I therefore wouldn't know if my deployed systems already have dozens of these dialogs on-screen, until maybe they eventually die big-time and the box reboots:-O. ... Now I have exception handler code all over the place - but does NOT get triggered. ...
    (microsoft.public.windowsce.embedded)
  • Re: Windows; its way or the highway. (Was Re: RISC OS 6 - no shadow modes?)
    ... VinceH wrote: ... Microsoft way is app-driven rather than data (including filing ... from one app, and possibly from all of them) lumped in together, though ... Tthese pictures needed to be at the printer of our ...
    (comp.sys.acorn.advocacy)