Dual monitors and full screen input issues

Started by
26 comments, last by JoshuaBaker 11 years, 8 months ago
I found another library that uses SlimDX, Gorgon is pretty advanced and has some examples you can run without Needing to compile...
here: http://code.google.com/p/gorgonlib/downloads/list

I tried his example "Animated Debate" (make sure you turn on vsync in his advanced options, use the arrow in the setup window) and the performance was exactly like mine, Terrible when moving the mouse around. Turn off second monitor and it has no problem.
Advertisement
Have you tried reproducing the issue in native code? If one of the D3D samples demonstrates the same issue, you'd at least know the problem wasn't in the managed code portion.
Mike Popoloski | Journal | SlimDX
What is the refresh rate on both monitors? Have you tried turning off Aero in windows 7 (the see through glass around windows)?

Vsync blocks Present() until the next vertical refresh. With a slower monitor refresh rate (< app's frame rate) your CPU is running ahead of the GPU. DX buffers up to a max of 3 frames of graphic commands (triple buffering), over that would induce FR drops and input lag. Turning on the second monitor only increases this lag because the OS is having to vSync 2 desktops (copying back buffers to surfaces).

To my knowledge, there is no way DX can get the time that the refresh happens and even if you could, you'd waste a lot of cycles- looping and doing nothing.
Is there a specific reason you want to use vSync? What are you trying to accomplish?

If you have to use it then you'll have to process your mouse and keyboard input in another thread which can be rather tricky because of deadlocks and the main thread (where Present() is ) blocked by vSync.

In my experience, I never use vSync. I lock the frame rate in code, measuring the elapsed time between each frame and use that ‘elapsed time’ to calculate the speed of movements and animations. Since I never use vSync I'm only familiar with what the documentation says it does not how it actually functions with other objects / code / situations.


Regards,
DJTN

What is the refresh rate on both monitors? Have you tried turning off Aero in windows 7 (the see through glass around windows)?

Vsync blocks Present() until the next vertical refresh. With a slower monitor refresh rate (< app's frame rate) your CPU is running ahead of the GPU. DX buffers up to a max of 3 frames of graphic commands (triple buffering), over that would induce FR drops and input lag. Turning on the second monitor only increases this lag because the OS is having to vSync 2 desktops (copying back buffers to surfaces).

To my knowledge, there is no way DX can get the time that the refresh happens and even if you could, you'd waste a lot of cycles- looping and doing nothing.
Is there a specific reason you want to use vSync? What are you trying to accomplish?

If you have to use it then you'll have to process your mouse and keyboard input in another thread which can be rather tricky because of deadlocks and the main thread (where Present() is ) blocked by vSync.

In my experience, I never use vSync. I lock the frame rate in code, measuring the elapsed time between each frame and use that ‘elapsed time’ to calculate the speed of movements and animations. Since I never use vSync I'm only familiar with what the documentation says it does not how it actually functions with other objects / code / situations.


Regards,
DJTN


I am working with a fixed timestep(not in the simple example obviously , but im my actual code). Also, you may not use vsync, but if i force it in my driver and i see this issues then im going to complain about how broken it is with vsync on :)



Have you tried reproducing the issue in native code? If one of the D3D samples demonstrates the same issue, you'd at least know the problem wasn't in the managed code portion.


Ill try to find somethign this evening, also im going to try a clean sweep of my driver just to be sure. The fact that this does not show up in other DX games is making me lean toward somethign in the managed code, but i don;t know for sure. Iv tried terraria, which is an XNA game and saw no issues.

I am working with a fixed timestep(not in the simple example obviously , but im my actual code). Also, you may not use vsync, but if i force it in my driver and i see this issues then im going to complain about how broken it is with vsync on


I don't think it's an issue with vSync or the driver but moreso, how you're handeling the input on a thread that is blocked until the monitor refresh occures and while the OS tries to vSync 2 desktops.


The fact that this does not show up in other DX games is making me lean toward somethign in the managed code


Maybe these other games are processing input on another thread when vSync is enabled.

Just sayin...
So i took a stab at using a second thread for rendering. I have very little xp with this so be wary of terrible code :)


using System;
using System.Windows.Forms;
using SlimDX.Windows;
using System.Threading;
using System.Drawing;
using SlimDX.Direct3D9;
using SlimDX;
using System.Runtime.InteropServices;
namespace DXTest {
static class Program {
static RenderForm Form;
static PresentParameters PresentParameters;
static Device Device;
static bool DeviceLost = false;
static bool running = false;
[STAThread]
static void Main() {
Form = new RenderForm();
Form.ClientSize = new Size(800, 600);
Form.FormBorderStyle = FormBorderStyle.None;
PresentParameters = new PresentParameters();
PresentParameters.BackBufferWidth = Form.ClientSize.Width;
PresentParameters.BackBufferHeight = Form.ClientSize.Height;
PresentParameters.BackBufferFormat = Format.X8R8G8B8;
PresentParameters.BackBufferCount = 1;
PresentParameters.SwapEffect = SwapEffect.Discard;
PresentParameters.DeviceWindowHandle = Form.Handle;
PresentParameters.Windowed = false;
PresentParameters.PresentationInterval = PresentInterval.Immediate;
Device = new Device(new Direct3D(), 0, DeviceType.Hardware, Form.Handle, CreateFlags.HardwareVertexProcessing, PresentParameters);
running = true;
Thread t = new Thread(Render);
t.Start();
MessagePump.Run(Form, () => {
if (DeviceLost) {
if (Device.TestCooperativeLevel() == ResultCode.DeviceNotReset) {
Device.Reset(PresentParameters);
DeviceLost = false;
}
}
});
running = false;
}
static void Render() {
while (running) {
if (DeviceLost) {
Thread.Sleep(100);
}
else {
try {
Device.Clear(ClearFlags.Target, Color.Black, 1.0f, 0);
Device.BeginScene();
Device.EndScene();
Device.Present();
}
catch (Direct3D9Exception e) {
if (e.ResultCode == ResultCode.DeviceLost) {
DeviceLost = true;
}
else {
throw;
}
}
}
}
}


}
}


Sadly this had no effect on what i was seeing, the mouse was still very jumpy and the problem still went away when i turned off my second monitor. Im at a complete loss here.

I found another library that uses SlimDX, Gorgon is pretty advanced and has some examples you can run without Needing to compile...
here: http://code.google.c.../downloads/list

I tried his example "Animated Debate" (make sure you turn on vsync in his advanced options, use the arrow in the setup window) and the performance was exactly like mine, Terrible when moving the mouse around. Turn off second monitor and it has no problem.

FYI, I just tried this example as well. And like I mentioned on your post on the Gorgon forum, I didn't see any performance issue. The mouse was a -little- laggy with vsync on, and I'm fairly sure that's just my awful code. I tried in 2 resolutions: 1440x900 and 1920x1200, with vsync on and off and I didn't get anything like you described. It's possibly a driver issue, but I do find it odd that you have other apps (like Terraria) working fine.

This is a stab in the dark, but have you tried different swap effects and various other presentation parameters (again, I didn't read all the replies, so apologies if this is a repeat)?
A small thing to add to this, my issues disappears when turning off desktop composition. This must say something, but im not sure what exactly.

This topic is closed to new replies.

Advertisement