Why does moving the mouse over an IMAQ image display slow the GUI down so much?

[egschaible]

I have a large application with several vi's running simultaneously under labview 8.6.1.  When I mouse over an image display control in one of the vi's, everything slows down a shocking amount in all the other vi's.  The windows task manager does not show a large increase in CPU use.  My pc is has a quad cpu with 4GB of RAM, and the CPU and memory loads do not appear to be terribly taxing to the system.  However, many of my vi's apparently come almost to a standstill if I just move the mouse in a circle around my image control.

This looks like it is largely a GUI display issue.  If I make a new vi and put a while loop in it that only displays the iteration loop number to an indicator, I can see the iterating occurring, then stopping totally when I mouse inside the image display control.  When I stop moving the mouse inside the control, or when I move it outside the control, the interation loop number jumps up, as if it had been incrementing behind the scenes the whole time.  So only display of the interating was halted.

This problem occurs even if the vi with the image control is not executing.  If the vi with the image control is open but not running, and I mouse over the image on it, the other guis all come to a screeching halt.

Does mousing in the image display control really utterly crush all other guis in all other labview windows?  Is this an issue inherent to the image display control?  If so, is there anything I can do about this? 

Also, this issue is not entirely limited to display.  I started looking at it in greater detail because this issue also exposed what I think is a race condition in my code.  I have a vi that acquires an image from a ccd and puts it into an IMAQ image.ctl.  This image then gets passed up to a vi up the call chain, and is put on a queue and sent over to be de-queued by a vi that has the image display control.  Here's the kicker:  when I mouse over the image display control, the image successfully gets acquired inside the subvi, and if I probe the wire leading to the output IMAQ image display.ctl, I see the image.  If I simultaneously probe the wire coming out of the subvi one level up the call chain, the image gets lost about half the time.  This only happens if I am mousing in the image display control IN A TOTALLY DIFFERENT AND SEPARATE VI.  If I bump up the priority of the ccd image acquisition vi to 'highest priority', the problem only happens about 1% of the time, and I really have to mouse around to make it happen.  Still, it's disturbing that mousing in the GUI in one window results in a failure of a separate subvi to simply pass an image up the call chain.  I understand that IMAQ images are referenced rather than passed by value, but I don't see why there should be a failure to pass the image up the call chain.  I've looked for a race condition, but can't find one.

Eric

[ZachAttack]

Could you post some code that demonstrates this behavior?  I'd like to take a look at it.

[ZachAttack]

I have tried to replicate this behavior in multiple ways.  I have not been able to see the same behavior.  I would suggest trying these same tests on a different computer to see if it occurs only on your computer.  You also might try a repairing the IMAQ drivers.

[egschaible]

I tried to create a minimal vi that shows the gui slowing down, and this is it (attached).  I see this behavior on my system even with this minimal vi, which is pretty minimal.  Since my last post, I have observed that the behavior goes away if the image displayed is 1000 x 1000 pixels or less.  In the attached vi, the image is 1500 x 1500.  If you run it and mouse over the image display control, the indicator named "numeric" will appear to stop updating.  On my system, I don't have to click or anything--just move the mouse over the image.  I would be interested to know whether you see the same behavior.

Thanks,

Eric

[Weiyuan]

Very easy fix, right click the image -> 16-bit display mapping -> 90% dynamic.   .

[ZachAttack]

Eric,

I have tried to replicate this behavior with the VI you have attached, but have been unsuccessful.  The numeric count continues to increment steadily regardless of where my mouse location is.  I will try this on other computers to see if I can find the problem.  You mentioned you were using LabVIEW 8.6.1, what version of NI-IMAQ do you have installed?  Also, what operating system are you running on?  Thanks for the additional information.

[NIquist]

It happens with my PC.  Once the image is loaded, moving the mouse in the display results in 50% CPU and slows the iterations to a crawl, even after I stop the VI. 

LV 10.02f2 (32 bit) -- IMAQ I/O 2.4 - IMAQdx 3.7 - NI Vision 10

Windows XP Pro - Ver 2002 - SP3

Dell Optiplex 755 - E8400 @ 3GHz - 2GB RAM

EDIT:  Just in case video drivers are causing the issue:  ATI Radeon X300/X500/X1050 - ATI Drivers (which I'll try to update, can't hurt to try right?)

[NIquist]

EDIT:  Just in case video drivers are causing the issue:  ATI Radeon X300/X500/X1050 - ATI Drivers (which I'll try to update, can't hurt to try right?)

---

No difference after updating Video drivers.

[egschaible]

I am using lv 8.6.1 with NI vision 10 (cf. attached jpg for list of versions as displayed in max).  I am seeing this behavior on both my lab computer and my desktop computer.

Lab computer:

Finetech Intel core 2 quad cpu Q9550 2.83GHz

Windows 7 professional 32-bit

4GB RAM

Nvidia GeForce 9800 GT

Desktop computer:

Dell Precision PWS490 Intel Xeon CPU 3.2GHz

Windows XP professional 32-bit SP3

3GB RAM

nvidia Quadro FX 580

Changing the 16-bit mapping to downshift does seem to help a bit, but I still get a total display freeze of the gui if I have a sufficiently large image in the display control.  Our ccd is 4008 x 2672, which is a large (~11 million pixels) image if the entire ROI is used.  If I set the 16-bit display mapping to full dynamic, I get the total freeze around 1500 x 1500 pixels.

Thanks for your help, and any suggestions you can give.

Eric

[ZachAttack]

I have finally been able to replicate the behavior that you are seeing on another computer once the image was large enough.  Here are a few notes about this behavior:

First. The UI only slows down when the images are large, 16 bit images.  The reason why this is unique to 16 bit images is that they can only be displayed on the front panel as 8 bit images.  The workaround that Weiyuan suggested to change the 16 bit display mapping hints towards the root of the problem...that any time a mouse runs over the indicator, Windows asks the entire image to re-draw (having a separate indicator overlapping the image will create the same behavior).  With a 16 bit image, not only does the image have to re-draw on the screen but the 16 bit pixels need to be mapped to 8 bits.  When setting the 16 bit display mapping to Full Dynamic, this requires mor computation/pixel than 90% dynamic or one of the other mapping schemes.

This is expected behavior if your program is running and you're trying to display a large 16 bit image.  To fix this behavior there are a couple options:

1. Change the 16 bit display mapping to something other than full dynamic.  You can choose which 8 bits to display or if you want to map the bits. 
2. Resize the image just for viewing purposes on your front panel (since you aren't going to view every single pixel of you image on the screen). You can use the IMAQ Resample.vi to do this.  This will allow you to take your 1500x1500 pixel image and only display a 500x500 pixel version.
3. If you are interested in viewing small details of the large image, consider just displaying a smaller region of interest at a time.

Let me know if any of these solutions work for you.  Good luck on your application.