Re: Fixed Framerate
From: Robert Dunlop [MS MVP] (rdunlop_at_mvps.org)
Date: 01/30/05
- Next message: Heinz Neidhart: "Re: ProcessCmdKeys in MDX applications"
- Previous message: Teis Draiby: "Re: Fixed Framerate"
- In reply to: Teis Draiby: "Re: Fixed Framerate"
- Next in thread: Teis Draiby: "Re: Fixed Framerate"
- Reply: Teis Draiby: "Re: Fixed Framerate"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 29 Jan 2005 20:01:36 -0800
"Teis Draiby" <teisREMOVE-THIS@draiby.com> wrote in message
news:u$NZvdmBFHA.3524@TK2MSFTNGP15.phx.gbl...
> For my (windowed) application that has a lot other tings to do than 3D, I
> could set a 'PresentationInterval.Two'-value to make D3D only process
> every
> second frame and still maintain a 36 fps framerate on a standard monitor.
> Thus saving processing time for the rest of the app.
Note that presentation intervals of two or higher require that the driver
support this. If it is supported that could work, as long as you flag
SwapChain.Present not to wait or you may be spinning for an extra frame
(meaning over 50% of time spent spinning in driver assuming your app could
render every refresh to begin with). An alternative would be to throttle
the framerate yourself by calling Present() no earlier than 1/36th of a
second after the last successful call to Present, and using a presentation
interval of one.
> But if this MSDN quote
> applies to the use of SwapChain.Present() it is not possible (if
> windowed):
> MSDN:
> "For a windowed swap chain, this value must be PresentInterval.Default
> (0).
> For a full-screen swap chain, it can be PresentInterval.Default or the
> value
> that corresponds exactly to one of the flags enumerated in Present."
Searching MSDN, the only place I seem to find this is in archived copies of
the managed DX documents (which unfortunately had a bit of catching up to
do). Here's the current docs for PresentationInterval:
Note in the description of Immediate: "This option is always available for
both windowed and full-screen swap chains."
> Seems like a 'waste' of a good opportunity to cut 3D processing time.
> Maybe I got the concepts wrong...
In addition to using the DoNotWait flag, a bit of re-ordering can help
matters here. Two things to take into account:
1. After EndScene() has been called, there will be some period of time
before Present() can succeed, even with a presentation interval of
Immediate. EndScene() simply tells D3D you are done sending commands, but
the GPU may still be rendering primitives you uploaded between BeginScene()
and EndScene().
2. After Present() returns successfully, on the other hand, the GPU is
ready to start rendering the next frame.
Thus you can squeeze in other non-D3D processing between EndScene() and
Present. Performing other tasks during this time helps increase performance
because the CPU can be doing other things while the GPU finishes up. So
instead of:
Render()
(i.e. BeginScene Render EndScene Present)
DoAppStuff
instead try:
Render()
(just: BeginScene Render EndScene)
DoAppStuff
Present()
-- Robert Dunlop The X-Zone http://www.directxzone.org/ 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.
- Next message: Heinz Neidhart: "Re: ProcessCmdKeys in MDX applications"
- Previous message: Teis Draiby: "Re: Fixed Framerate"
- In reply to: Teis Draiby: "Re: Fixed Framerate"
- Next in thread: Teis Draiby: "Re: Fixed Framerate"
- Reply: Teis Draiby: "Re: Fixed Framerate"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|