I'm trying to understand why there's a long green frame of 872.9ms when it appears that not much is going on. All the little tasks are around 4ms. I'm expecting to see each of those wrapped in their own frame. That last task is big, and that's what I'm working on.
I enabled the FPS meter to make sure that it's not a Performance Monitor bug. FPS drop to 1, so I think the Perf Mon is working correctly.
Related
I find that Microsoft's decision to provide cursor updates in the AcquireNextFrame loop causes a huge performance hit when the cursor is being moved around.
When I turn on a millisecond-level clock in the browser, AcquireNextFrame can capture 60 frames of data, and the interval between each frame is very average, but if the mouse moves frequently, the captured data will be less, and the interval between each frame is very uneven.
I found that someone asked this question earlier than me on https://www.reddit.com/r/VFIO/comments/f22k6u/windows_capture_performance_dxgi_bug/
Is there any way to make the function AcquireNextFrame work around this performance issue?
What is the preferred way of synchronizing with monitor refreshes, when vsync is not an option? We enable vsync, however, some users disable it in driver settings, and those override app preferences. We need reliable predictable frame lengths to simulate the world correctly, do some visual effects, and synchronize audio (more precisely, we need to estimate how long a frame is going to be on screen, and when it will be on screen).
Is there any way to force drivers to enable vsync despite what the user set in the driver? Or to ask Windows when a monitor rerfesh is going to happen? We have issues with manual sleeping when our frame boundaries line up closely to vblank. It causes occasional missed frames, and up to 1 extra frame of input latency.
We mainly use OpenGL, but Direct3D advice is also appreciated.
You should not build your application's timing on the basis of vsync and exact timings of frame presentation. Games don't do that these days and have not do so for quite some time. This is what allows them to keep a consistent speed even if they start dropping frames; because their timing, physics computations, AI, etc isn't based on when a frame gets displayed but instead on actual timing.
Game frame timings are typically sufficiently small (less than 50ms) that human beings cannot detect any audio/video synchronization issues. So if you want to display an image that should have a sound played alongside it, as long as the sound starts within about 30ms or so of the image, you're fine.
Oh and don't bother trying to switch to Vulkan/D3D12 to resolve this problem. They don't. Vulkan in particular decouples presentation from other tasks, making it basically impossible to know the exact time when an image starts appearing on the screen. You give Vulkan an image, and it presents it... at whatever is the next most opportune moment. You get some control over how that moment gets chosen, but even those choices can be restricted based on factors outside of your control.
Design your program to avoid the need for rigid vsync. Use internal timings instead.
The setup
The game in question is using CoreAudio and single AudioGraph to play sounds.
The graph looks like this:
input callbacks -> 3DMixer -> DefaultOutputDevice
3DMixer's BusCount is set to 50 sounds max.
All samples are converted to default output device's stream format before being fed to input callbacks. Unused callbacks aren't set (NULL). Most sounds are 3D, so azimuth, pan, distance and gain are usually set for each mixer input, not left alone. They're checked to make sure only valid values are set. Mixer input's playback rate is also sometimes modified slightly to simulate pitch, but for most sounds it's kept at default setting.
The problem
Let's say I run the game and start a level populated with many sounds, lot of action.
I'm running HALLab -> IO Cycle Telemetry window to see how much time it takes to process each sound cycle - it doesn't take any more than 4ms out of over 10 available ms in each cycle, and I can't spot a single peak that would make it go over alloted time.
At some point when playing the game, when many sounds are playing at the same time (less than 50, but not less than 20), I hear a poof, and from then on only silence. No Mac sounds can be generated from any application on Mac. The IO Telemetry window shows my audio ticks still running, still taking time, still providing samples to output device.
This state persists even if there are less, then no sounds playing in my game.
Even if I quit the game entirely, Mac sounds generated by other applications don't come back.
Putting Mac to sleep and waking it up doesn't help anything either.
Only rebooting it fully results in sounds coming back. After it's back, first few sounds have crackling in them.
What can I do to avoid the problem? The game is big, complicated, and I can't modify what's playing - but it doesn't seem to overload the IO thread, so I'm not sure if I should. The problem can't be caused by any specific sound data, because all sound samples are played many times before the problem occurs. I'd think any sound going to physical speakers would be screened to avoid overloading them physically, and the sound doesn't have to be loud at all to cause the bug.
I'm out of ideas.
Reading Jeff Willcox on frame rate counters, I realized my application rarely hit the 60 fps. I'm not satisfied with the global performance of my app (compared to its iPhone counterpart), but the numbers seems weird to me.
When the app is doing nothing, even just after launch, it's even sometimes at 0 fps. And the higher I hit is 50 fps.
Overall, my application is not blazing fast, but not really slow. So how can I interpret the numbers ? How can I spot the issue that makes my app have a bad fps ?
A low frame rate doesn't necessarily indicate poor performance.
If you're testing on an actual device and you see poor performance when then an investigation may indicate a problem that may be related to an issue which also impacts frame rate.
Hmmm. That sentence may not be clear.
Don't worry too much about getting a high frame rate all the time. Focus on actual performance experienced by the user.
If the actual performance is poor and the frame rate is low, that's when you should worry about the frame rate.
What's important is testing on an actual device and what performance is like there.
Jeff Wilcox notes in his post that:
Frame rate counters may be 0 when there is no animation being updated on the thread at any particular moment. You can add a very simple, continually animating and repeating, animation to your application during development & testing if you want to ensure that there is always some frame rate value available.
So the 0fps reading seems not be an issue since no screen updates need to be rendered.
I just wrote a custom progress bar, it's single buffered and will remain so. How many frames per second are desirable for something like this? I don't want to waste too much CPU updating the screen unnecessarily.
As a rule of thumb, 10 fps is a reasonable minimum for very small, simple animations with motion. 30 fps is a minimum for more complex motion and/or larger scenes.
However, generally progress bars have very little change from frame to frame. If you are using a very simple animation, you may find that less than 10fps works.
I suggest starting at 10fps and checking the result. Tune from there.
You might want to go the other way around and update the progress bar whenever there is a pixel of bar to update. If you have a 200 pixel bar, then update it when each 0.5% of the processing is completed. That’s every 300 ms for a 1 minute process but every 4.5 s for a 15 min process. As the examples indicate, the fps will generally be slower than you’d need for smooth large-motion animation; otherwise, you wouldn’t need a progress bar. Depending on your design, it may be easier to have the process announce to the progress bar each time it completes x% than to have the progress bar keep checking process every n ms.
I'd be happy with an update per second or two for functional purposes.
10-20 fps if you want it to look good.