Dual Monitor Stuttering
Author
We are experiencing a problem with one of our projects. The hardware setup for the project involves the following:
- Windows XP Professional SP3
- Intel core 2 duo E8400 @ 3.0GHz
- 2 LCD monitors configured as Dualview
- Primary monitor is 1920x1080 @ 60Hz
- Secondary monitor is 1280x1024 @ 60Hz
- Tried on both a single GeForce 9600GT and a single 9800GT
Both monitors have a seperate window (running in borderless windowed mode), due to the screens having different resolutions. The primary monitor contains a quad with a texture applied that is updated using glTexImage2D to upload the result of a ffmpeg decoded H.264 high definition 1080p .video stream (decoding itself is running in a seperate thread). The secondary monitor has a fairly simple OpenGL scene with a few models and shaders applied.
The actual problem we are experiencing is a periodic variance in rendering times. With vsync enabled we typically get render times for both screens reported as about 0.0333 seconds (30fps), however, every 20 seconds or so (at completely unpredictable times), the render time starts fluctuating within the bounds of 0.0333 to 0.0166 seconds (60fps) and back, which causes a nasty stuttering effect. After a couple of seconds it will then stabalise back to 0.0333 seconds. What's more, usleeping or spin-looping to make up the extra time doesn't seem to help, suggesting something more sinister is occurring. Turning vsync off seems to lead to constant stuttering (as well as tearing), but an average frame rate of 70 - 100 fps.
The only thing that seems to work is setting the CPU affinity for the application, but this then causes excess load on a single core (due to decoding), leading to slowdown in frame rate during heavily encoded sections of the video - but it does completely stop the random stuttering problem.
If I run both the windows in fullscreen mode, the stuttering seems to still occur, but is now reported as a drop in framerate, rather than an increase.
I've also looked at all the performance counters I can think of, such as paging, cache copies, disk access, CPU usage and memory bandwidth. All seem to be within reasonable limits and there are certainly no spikes that correlate to the observed behaviour.
I've also tried all the driver settings I can think of, including turning off 'threaded optimization'. Rolling back to older drivers doesn't help either. Interestingly, if I don't render either of the windows, the stuttering goes away. Moving both windows to the same monitor also stops the stuttering.
I'm pretty much out of ideas, but it definitely seems to be some sort of multi-monitor and multi-threading timing issue that's going on.
Can anyone shed any light on this issue, or suggest any work arounds? I'm out of ideas!
Sorry for such a long post!
Earl
Quote:
The actual problem we are experiencing is a periodic variance in rendering times. With vsync enabled we typically get render times for both screens reported as about 0.0333 seconds (30fps), however, every 20 seconds or so (at completely unpredictable times), the render time starts fluctuating within the bounds of 0.0333 to 0.0166 seconds (60fps) and back, which causes a nasty stuttering effect. After a couple of seconds it will then stabalise back to 0.0333 seconds. What's more, usleeping or spin-looping to make up the extra time doesn't seem to help, suggesting something more sinister is occurring. Turning vsync off seems to lead to constant stuttering (as well as tearing), but an average frame rate of 70 - 100 fps.
I think that it is really hard to pretict the timing of a single frame in such a setup. I don't think that you will be able to handle this issue by enabling/disabling hardware, multithreading or multimonitor support.
The issue is quite simple: Your average frame needs just a little bit more than 1/60 seconds to be rendered and decoded, this means, with vsync on, you need two "monitor" frames, resulting in a fps of 30.
Now lets say your videocompression has some scene which need less decompression to do which will results in a short period of time where your frame needs just less then 1/60 seconds to be rendered. In this case you just need one frame, which leads to a fps of 60.
If you want to enforce continious fps, you need to skip frames or just wait. Lets say you want to enforce 30fps, then turn vsync on, measure the time at the start of each frame. When you want to swap the buffers, you need to compare the current time with the frame start time. If it is less than 1/60s , wait (sleep(...)) until atleast 1/60s from the start of the frame has been passed.
This will atleast prevent too fast rendering, but slowdowns should be handled differently (like skipping a videoframe).
Good luck :)
Quote:Original post by earl
Both monitors have a seperate window (running in borderless windowed mode), due to the screens having different resolutions. The primary monitor contains a quad with a texture applied that is updated using glTexImage2D to upload the result of a ffmpeg decoded H.264 high definition 1080p .video stream (decoding itself is running in a seperate thread). The secondary monitor has a fairly simple OpenGL scene with a few models and shaders applied.
Actually, you should use glTexSubImage2D instead of glTexImage2D if you want to update a texture. glTexImage2D can cause a dealloc and a realloc.
There is also the problem of format. It is best to use 32 bpp.
Make it a GL_BGRA format.
glTexImage2D(....., GL_RGBA8, w, h, 0, ...., GL_BGRA, ....pixels);
does it occur with mouse movement?
If u have nview enabled then turn it off
It causes massive stuttering with opengl/d3d apps
If u have nview enabled then turn it off
It causes massive stuttering with opengl/d3d apps
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement