I have been experiencing this behavior since I have switched to 2022 versions, but I wasn’t able to create some reproducible example as this sometimes appeared and sometimes disappeared (or at least I thought so).
However I have now noticed it happens regularly while using Lister component, so here is a small example. Please jump into perform mode with following scene and observe that selection in Lister is delayed (when compared to mouse) by couple of frames. It isn’t a big deal, but it kinda doesn’t feel right
Its very hard to capture using TD / OBS / ffmpeg, so I am attaching video from phone that shows what is happening on my system. Thanks
mouse_select_lag.1.toe (12.9 KB)
demo.mp4.crash (1.0 MB)
I’m unable to reproduce at the moment.
Are you dropping frames at all when you are moving your mouse around the lister?
What are the specs of your machine again?
Hi @JetXS I am sorry - I forgot to include my specs.
I am using
Dell Precision 7710 Workstation Laptop
Intel(R) Xeon(R) CPU E3-1575M v5 @ 3.00GHz, 64GB RAM
NVIDIA Quadro M5000M (driver 516.25)
I guess it isn’t directly related to Lister as it happens also when I am moving mouse over simple buttons / parameters / opviewers / anything really. I believe it isn’t a performance problem - or at least it doesn’t seem that way. When looking at fps and droppped frames, nothing happens during this lagging. I also think it is somehow related to exclusive mode (when running on fullscreen), as it doesn’t happen when having perform mode with borders.
EDIT - removing link from cloud storage
Attaching another video that includes performance stats. Feel free to remove .crash extension and extract the video from archives.
mouse_lag_2.7z.002.crash (341.5 KB)
mouse_lag_2.7z.001.crash (4 MB)
It might sound like a silly question but… are you trying with a mouse ? What happens if you use the trackpad ?
It’s a really odd one.
We noticed that in some cases, some bloatwares could have a negative impact on TD with the new Vulkan builds.
Do you have maybe one of these installed ?
Dell Customer Connect
Dell Digital Delivery
Dell Help and Support
Dell Product Registration
Dell Support Assist & Remediation & Agent
Dell Update - SupportAssist Update Plugin
Hmm, that is interesting. When using trackpad, lag is much lower, but still present. However it is much harder to notice - when using trackpad, one could only see it with fast mouse movements. Nevertheless its still there - lets say about two frames behind normal behavior.
I tend to be quite picky about what I install, so none of these Dell bloatwares are present on my system. But maybe there is something innocent looking causing this, who knows… I guess the only way to find out would be to do clean install?
While testing this in heavier scene I have noticed there is almost no difference between lag when using mouse vs trackpad (both causing heavy delay which wasn’t present in 2021 versions).
Total shot in the dark, but I’ve experienced selection lag in the past caused by trackpad drivers, because they don’t send along the original click until the doubleclick or double tap to drag threshold window has passed. Again, just a shot in the dark, but have you tried uninstalling just the trackpad drivers (synaptics or dell or whatever they may be)?
Thanks for the tip - I have tried uninstalling Dell Touchpad driver, but unfortunately it haven’t changed this behavior.
Update: It seems like this is related to some piece of software installed on my system (as @JetXS suggested). I have installed clean Windows on second laptop (with the same specs as this one) and no lagging was present there. Once I figure out what exactly is causing this I will post it here.
We have an issue logged to be investigated further with increased input latency at low framerates.
Your case is odd because you mentioned not dropping frames.
Please let us know if you find anything related to possible bloatware.
Thanks @JetXS, but so far I don’t feel like it is related to low framerates (or at least I haven’t tested such scenario).
Oh, I was completely wrong here. It definitely isn’t related to any kind of bloatware. While testing this further, I have realized this is happening also on freshly installed system (one that I have tested yesterday).
(This system has clean install of Windows 10 with all all unnecessary apps uninstalled. I have installed only nvidia driver + TD. Therefore I think it is safe to say it isn’t caused by some piece of other software.)
Nevertheless I have found out that this lag is only happening when window resolution is set to exactly match monitor resolution (and is without borders). If it is bigger or smaller than monitor (one pixel difference is enough), it doesn’t lag at all. That is why I have originally thought it works on this freshly installed system - my window COMP was set to slightly larger resolution than my monitor.
I think I can tell the difference and reproduce with those extra details.
Logging an issue to investigate further.
While looking at this behavior in the meantime, I realized the lag might not necessarily be related to mouse. It seems more like the whole graphics is delayed by couple of frames.
For example when using keyboard as input, there is the same lag as when using the mouse. Also when displaying some incoming data, lag seems to be also there. Based on this I realized this might not be related to mouse at all - but rather to the way graphics is being drawn. Not sure if this helps somehow, just wanted to say what I found out
I have just stumbled upon a problem, that might be related to this.
Please take a look at following files. There is a simple scene with Engine COMP in it. Engine is outputting spinning banana and it works just fine until I get into exclusive mode (just by hitting ctrl+b shortcut in perform mode) and start moving mouse over lister. At this point both lister and engine output is lagging (though engine’s lagging seems to be much worse when compared to lag on lister).
engine_lag.zip (3.0 MB)
EDIT: @bangnoise please may I ask whether you think something strange might be going on with this example in terms of Engine COMP?
I am currently working on a larger project where I have observed somewhat similar lagging, but it is much harder to reproduce (it isn’t happening in the same situation as here - exclusive mode or mouse input doesn’t trigger it there). Nevertheless I feel like it might be somehow related (visually the lagging looks just the same, but once it starts, it doesn’t seem to stop so easily ). I am kind of stuck here as it happened couple of times and I haven’t figured out what might be causing it. I was hoping that if you find some strangeness here, it might also solve the problem there. But maybe it is something completely different. Thanks
Hello, I just wanted to let you know I have tested this graphics lag on a new experimental branch and it seems to have the same problem - heavy lag is present there too.
I’ve been looking into this for a while, it’s a pretty strange issue. One thing that I’ve found seems to fix it is if you install the latest Nvidia Graphics drivers, and go to the Nvidia Control Panel, under ‘Manage 3D Settings’, go to the bottom and set ‘Vulkan/OpenGL present method’ to be ‘Preferred Layered on DXGI swapchain’.
Does that help the issue for you? I need to talk to Nvidia about this to see why it isn’t the default behavior and what the tradeoffs are.
@malcolm thank you very much for looking into this. I have just tested it with DXGI swapchain set in control panel and it fixed the issue, yey!
There is still a very little difference when compared to snappiness of “windowed” perform mode. However it is hardly noticable - I had to really focus to see the difference (based on slowmo screen recording it seems to be just one more frame of latency in exclusive mode when compared to windowed mode). I think this is completely fine as it doesn’t disturb me as a user.
Before this fix was the lag on my system huge - especially on highdpi monitor it seemed to be amplified, making the interaction with UI super hard. But this is great, thank you once again! Please let me know if you find out if there are some possible downsides when using this Vulkan/OpenGL present method.
I think I’ve found a fix to this that should work in general. Thanks for the report!