According to this article by Microsoft the screen refresh rate set by the user can be (and is mostly) a fractional number. The user sets 59Hz but the screen runs according to the on screen display at 60Hz, but in reality it's 59.94Hz. What I need for a extremely smooth animation is the 59.94Hz.
Using IDirect3DDevice9::GetDisplayMode I only get an int value which cannot by definition represent the real timing (same goes for EnumDisplaySettings). I encounter a visible stutter about every second because it reports the rounded/truncated 59. If I manually correct the reported timing in my application to 59.94 it runs smooth.
Anybody knows how I can retrieve the real screen refresh rate?
My current workaround is mapping 60Hz and 59Hz both to constant 59.94Hz but that's not satisfying.
If you are targeting Windows Vista or later, the answer depends on the mode in which your app is running.
If it is a windowed app (or windowed full-screen), refresh rate is controlled via the Desktop Window Manager (DWM) according to user settings and other factors. Use DwmGetCompositionTimingInfo and look at DWM_TIMING_INFO::rateRefresh to get the monitor refresh rate.
If the app is true full-screen, then the full-screen swap chain you create overrides the system default. However, your selected refresh rate (DXGI_SWAP_CHAIN_FULLSCREEN_DESC::RefreshRate) should match one of the monitor-supported refresh rates. You can get the list of supported refresh rates using IDXGIOutput::GetDisplayModeList. Here's an example of how to do so:
UINT numModes = 0;
dxgiOutput->GetDisplayModeList(DXGI_FORMAT_B8G8R8A8_UNORM, 0, &numModes, NULL);
DXGI_MODE_DESC* modes = new DXGI_MODE_DESC[numModes];
dxgiOutput->GetDisplayModeList(DXGI_FORMAT_B8G8R8A8_UNORM, 0, &numModes, modes);
// see modes[i].RefreshRate
In any case, you shouldn't see glitching if you're triple-buffered. You should just present as fast as you can and the OS will present on time. If you combine triple-buffering with custom managed frame timing, you're guaranteed to not actually get triple-buffering, and you'll get glitches any time there's drift in the vblank phase (which happens gradually even if you have a perfect value for refresh rate). If you want to stick with triple-buffering, just present as fast as you can and let the OS take care of presentation timing. If you're using your own timing to drive Present()s (for example, to get low-latency response), you should throw in a call to IDXGIOutput::WaitForVBlank on another thread to help synchronize frame timings. If you end up doing that, you should also use IDXGISwapChain::GetFrameStatistics to make sure you recover from any spurious glitches, otherwise you'll end up a frame behind.
Good luck!
Related
In older versions of MacOSX, one would use
UpdateSystemActivity(UsrActivity);
In order to reset the screensaver timer.
In modern versions of MacOSX, the most commonly recommended solution is:
static IOPMAssertionID activity_assertion_id = kIOPMNullAssertionID;
IOReturn r = IOPMAssertionDeclareUserActivity(CFSTR("FractalUserActivity"),
kIOPMUserActiveLocal, &activity_assertion_id);
or
IOReturn result = IOPMAssertionCreateWithName(
kIOPMAssertionTypeNoDisplaySleep,
kIOPMAssertionLevelOn,
CFSTR("FractalNewFrameActivity"),
&power_assertion_id);
IOPMAssertionRelease(power_assertion_id);
However, neither of these in my testing appear to actually reset the MacOSX Screensaver timer. When I set my screensaver to 1minute, but run the above code in a loop at 60FPS, the screensaver still turns on eventually.
Often it's said that IOPMAssertionRelease should only be called after the screen no longer wants to be held awake, but I don't think that's the functionality I need. I need to simply reset the 1min screensaver timer. Because, the timer should be reset every single time a framebuffer gets rendered [due to the application changing what's being displayed]. But, if no frame gets rendered in a 1minute interval, the screensaver should be displayed.
Is there no way to do this in modern versions of MacOSX? Chromium currently exhibits the exact feature that I desire. When watching a YouTube Video, 1minute after the video ends, is when the screensaver will turn on, regardless of how long the youtube video is, even if it's e.g. a 10min Youtube Video.
~ I don't want to hardcode 1minute, since obviously it should regardless of what your screensaver time setting is.
I am creating a Cocoa application in Xcode 6, and the application uses an OpenGLView. The draw method in my extension of NSOpenGLView is getting called repeatedly, but I am not sure at which rate it is being called or a way to set the rate.
Is there a default "framerate" for NSOpenGLView, and is there a way to change it?
Apple has a technote describing how to drive an OpenGL rendering loop. The answer is to use a CoreVideo display link (CVDisplayLink), it will call a callback during the blanking interval.
Generally in any window system, the window is not redrawn on a periodic schedule; it only happens in response to events that cause a "damaged" or "dirty" state.
The number of things that cause this "damaged" state has gotten a lot smaller in recent years thanks to compositing window managers (OS X uses one such window manager). It used to happen whenever a window moved over top it, but in modern window managers it only happens during/after a resize event or when the window is moved.
As you would expect, Cocoa's documentation says the same thing:
- update
Called by Cocoa when the view’s window moves or when the view itself moves or is resized.
Owen Taylor writes an excellent blog; this diagram illustrates what may happen:
If a compositor isn’t redrawing immediately when it receives damage from a client, but is waiting a bit for more damage, then it’s possible it might wait too long and miss the vertical reblank entirely. Then the frame rate could drop way down, even if there was plenty of CPU and GPU available.
I have an owner drawn control which displays data. The data changes over time. I need to find a fast way to continuously update the control.
I tried using timers, but the problem is that the timer alone runs at maximum of 65 frames per second. And if control's paint method takes time, the fps becomes quite low.
I tried requesting update (InvalidateRect) from control's paint method, this way it repaints the control hundreds of times per second, however the rest of the UI doesn't work properly (e.g. buttons not updated, tooltips are frozen, etc).
What's the proper way to update an owner drawn control as fast as possible, still keeping the UI responsive?
P. S. I need this to work with GDI, so I can't use OpenGL/Direct3D to display my data.
If you want to update it literally as fast as possible, run a message loop that doesn't wait for input. If you continue to process messages the UI will stay responsive but when there aren't any messages your control will continue to update.
Psuedo-code:
while (!fQuit)
{
while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
DispatchMessage(&msg);
RepaintControl();
}
Depending on how your control is implemented, the "repaint" function might be as simple as:
RedrawWindow(hwndControl, 0, 0, RDW_INVALIDATE | RDW_UPDATENOW);
If you find this bogs your machine down too much (although with multi-core it should be ok) or is updating too quickly, you could use a waitable timer to get a higher-resolution update while still yielding control at times. See Using Waitable Timer Objects for details on waitable timers.
There are some controls on windows phone that behave different on the first interaction with them than on subsequent ones. e.g. a button control takes about 3-5 seconds to initialize the required action the first time the button is pressed, however on subsequent clicks it works immediately.
Another usercontrol that adjusts its height based on the key press doesn't adjust properly the first time, however the second time it works.
Is there a way to either prepare the controls, i.e. set them in a ready state so that all the clicks behave the same, or can first click can be faked to bypass this annoying behaviour?
Also what is causing this problem?
NB:- I am testing on a Lumia 520 device.
Unfortunately There is no way to prepare the controls. Nokia Lumia 520 comes in Lower Memory Device So Its behaviour seems slow at loading first time in memory and there are so many Background tasks also runnig at a same point of time. You should try it in Higher Memory Device and see the Behaviour.
I found out from this app performance document why it was happening , http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967560(v=vs.105).aspx#BKMK_Applicationstartup.
I have a loading panel that is set to collapsed by default and only set visible once the button is clicked. According to the document, elements in collapsed state arent added to memory, so this means the first time it needs to initialize the panel and it doesnt need to in subsequent tries.
The other UI control behaving weirdly was also due to its parent's height not being adjusted after its own height is adjusted the first time, so adjusting the parent height as well fixed it.
I develop audio plugins, which are run inside their hosts and work realtime. Each plugin has its own window with controls, which often contains some kind of analysis pane, a pretty big rectangle that gets repeatedly painted (e.g. 20-50x per second). This is all working well.
The trouble comes when the user adjusts a parameter - the plugin uses WM_MOUSEMOVE to track mouse movements and on each change calls ::InvalidateRect to make the relevant portion of the window be redrawn. If you move quickly enough, the window really gets quickly repainted, however there seems no time for the host and other windows to be redrawn and these usually perform some kind of analysis feedback too, so it is really not ideal.
No my questions:
1) Assuming the host and other window are using ::InvalidateRect too, why mine is prioritized?
2) How to make ::InvalidateRect not prioritized, meaning the window needs to be invalidated, but it may be later, the rest of the system must get time for their redrawing too.
Thanks in advance!