06-14-2012 11:39 AM
Hi uknoblich,
This is interesting. I ran the code you referenced and I observed the same behavior. When anti tearing was false the window updated on both screens, but when I set anti tearing to true the window only updated on my primary screen.
06-14-2012 08:26 PM
Good to hear you can replicate this behavior. That's the first step to getting a fix, I hope!
Another issue we noticed (which might be related) is that when non-tearing is off, a movie will play on either screen, but updates seem less smooth and somewhat choppier on the secondary one.
We'd like to use our setup to present visual stimuli to a subject on a second (and/or third) screen that's different from the main display (which is showing the control panel to the experimenter), so in the very least we need smoothly updating movies, but really we also do need non-tearing updates.
Ulf
06-15-2012 04:33 PM
Hi uknoblich,
I was also able to replicate the behavior and found that Corrective Action Request (CAR) #343762 has been filed to our R&D department. You can always check if CARs have been fixed by looking at the release notes of future LabVIEW versions. Thanks for bringing this to our attention.
Have a great weekend,
06-11-2015 11:16 AM
Hi Allison,
I got same problem here in Labview 2014 SP1. Have no solutions been found?
06-12-2015 02:40 PM
Hi bmol,
It is still a known issue. I'm not certain what the timeline for the fix is, though it will probably not be in the next version.
02-11-2019 08:56 AM - edited 02-11-2019 09:16 AM
Hello! Is it any updates concerning this issue? Now is year 2019 and issue is still present (at least in LV 2018). We have the same need as one of the previous posters - we wish to show nice and smooth visual stimulus to animal, but it looks like it is possible only on the primary screen.
UPD: of course there is a workaround (image control + Synchronous display instead of WinDraw), but in my case it costs something like 2x of CPU, which is not very good in some cases.
02-12-2019 05:47 PM
Hi D_mitriy,
It looks like this forum post is fairly old and may not receive the activity you need to find an answer. I would recommend posting a new thread and reference this one so people have context.
Best,
10-08-2019 08:44 AM
My speculation is that the WindDraw in the "non-tearing mode" relies upon a technology that implements a double buffer scheme to vsync to prevent tearing.
That works well if you have a simple configuration and a dedicated GPU.
This doesn't work well if you have a modern situation: e.g. have a laptop (which may elect to save battery with an integrated graphics), you have multiple monitors (where the refresh cycles are not phase locked and so the vsync of the monitors are different), etc....
Perhaps the underlying code that detects the vsync wasn't built for multiple monitors, or multiple graphics boards, and is listening to the wrong source? If you point Dependency walker at NIVisWnd.dll, you'll find a lot of GDI32.DLL and GDIPLUS.DLL which is as old as WinXP, so perhaps it's time that WindDraw gets an update.
10-08-2019 09:15 AM - edited 10-08-2019 09:22 AM
@D* wrote:
Perhaps the underlying code that detects the vsync wasn't built for multiple monitors, or multiple graphics boards, and is listening to the wrong source? If you point Dependency walker at NIVisWnd.dll, you'll find a lot of GDI32.DLL and GDIPLUS.DLL which is as old as WinXP, so perhaps it's time that WindDraw gets an update.
Changes for that are pretty small. An update won't do the job. The whole External Window part of the IMAQ Vision shared library that is used under the hood is likely needing to be completely rewritten to fix this. Considering that the External Window library in IMAQ Vision is a legacy solution that originates from the beginnings of the Concept V.i library that NI later acquired and turned into IMAQ Vision, because LabVIEW at that time had no IMAQ Vision control to display images in, chances are higher that the entire External Window library of IMAQ Vision is completely removed rather than rewritten!
Part of the reason why your IMAQ Vision Control is probably slower when updating your image compared to IMAQ WindDraw, is that it goes through the proper graphic interface routines rather than directly to low level GDI calls that were developed when multiple monitors were a very strange setup for a computer.
10-08-2019 09:54 AM
Thanks for all the replies.
So the original reason for using IMAQ WindDraw was to be able to display video full-screen (something like the IMAQ Display, but without the borders). Is there a way to do this using non-WindDraw methods? If so, how?
Thanks,
Bruce