Darren's Weekly Nugget 11/06/2006

Darren's Weekly Nugget 11/06/2006

Post by Darre » Wed, 08 Nov 2006 02:40:07


As I mentioned in <a href=" http://www.yqcomputer.com/ ;message.id=212920" target="_blank">last week's nugget</a>, I've been working a lot with the Picture Control lately.  The other day, I was debugging what I *thought* was a race condition in my code for a long time.  But ultimately, my code was fine...it was my lack of understanding of a little-known LabVIEW quirk that was causing the problem.
 
Have you ever noticed the "Synchronous Display" option on controls and indicators?  You can find it by right-clicking on a control or indicator and going to the "Advanced" submenu.  Well, I remember when I first learned LabVIEW almost eight years ago, I noticed the Synchronous Display option in the right-click menus, and I always wondered what it was, but I never really took the time to figure it out.  Well, it turns out the LabVIEW Help has a <a href=" http://www.yqcomputer.com/ #Screen_Display" target="_blank">great description</a> of what Synchronous Display actually means, and this help topic ultimately gave me the answer to my problem.  
 
To summarize, all controls and indicators default to Asynchronous Display...in other words, the "Synchronous Display" option is unchecked.  What this means is that, when you give LabVIEW a new value for that control or indicator (usually via its control terminal or a local variable), it will update the appearance of the front panel object with the latest value whenever it gets a chance, i.e. whenever the user interface thread gets a chance to run.  In other words, some draws may never happen.  If you select Synchronous Display, however, you are essentially forcing LabVIEW to update that control or indicator immediately upon its value being changed on the diagram.  There's a really simple way to see the effect of this option.  Create a VI with a For Loop that runs 10000 times, and wire the iteration terminal to a numeric indicator.  Run the VI...it should return instantaneously.  Now right-click the indicator and choose Advanced > Synchronous Display.  Run the VI again.  It should take a LOT longer, because you are forcing LabVIEW to update the appearance of that indicator every single time its value is changed.
 
So in my case, I was drawing different components of a Picture Control, with the "Erase First" option deselected...this means that new images are drawn "over" old images, and the old images remain in the Picture Control.  Well, if two draws happened in quick succession (which was possible since I was keying off of Mouse Move events to do some of my drawing), sometimes, the first draw would never happen, due to the Asynchronous Display behavior.  As a result, portions of my picture that needed to be there from the first draw would never appear.  Now you see why I thought it was a race condition...depending on how fast my Mouse Moves occurred, I might see my first image, and I might not.  My problem was fixed simply by enabling Synchronous Display on my Picture Control. 
 
-D P.S. - Check out past nuggets <a href=" http://www.yqcomputer.com/ ;message.id=1669" target="_blank"> here</a>. Message Edited by Darren on 11-06-2006 11:18 AM
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Darre » Wed, 08 Nov 2006 06:10:10

By default, Synchronous Display is disabled, so unless you actually changed the setting on any of your controls or indicators, you should be safe.  But for those of you <a href=" http://www.yqcomputer.com/ " target="_blank">VI Analyzer 1.1</a> users out there, I've attached a VI Analyzer test below (saved in LabVIEW 8.0 format) that will return a failure on any control or indicator in a VI that has the Synchronous Display option set.  You can copy this LLB to your [LabVIEW Data]\VI Analyzer Tests folder and it will show up in the Tests tree the next time you use the VI Analyzer.
 
And not to be picky, but Warren's example above won't catch controls or indicators inside Tab Controls or Arrays.  The attached VI Analyzer test will find all those cases.
 
-D


Synchronous Display.llb:
http://www.yqcomputer.com/

 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Wed, 08 Nov 2006 08:40:22

Darren:
Do you think we should file a bug report such that if the user turns
off "Erase First" then "Synchronous Display" is automatically turned
on? I've read your post and I'm trying to imagine a case where I've
turned off "Erase First" where my draw *doesn't* depend upon getting
all previous draw updates, and I can't imagine one. Since I need all
previous draw states, then I better stop and wait for them to all get
there before I process the next one. It seems like these two options
need to be tied together.

-- Stephen
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Darre » Wed, 08 Nov 2006 11:40:07

I thought about that too, but it seemed to me that there would be no easy way to indicate to the user that the two options are linked in that way.  If we can figure out an easy way to link the two options, then I think it would be a good idea...it would have saved me a lot of erroneous debugging.
-D
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Thu, 09 Nov 2006 01:40:07

Making the VI run in the UI thread wouldn't fix the draw problem since
it would still only actually do the draw when there was no other work
to be done. In fact, since the VI is now tying up the UI thread, if the
VI goes to do some long disk operation, which would normally give the
UI a chance to update, I would guess that setting the VI to be UI would
result in fewer updates of the screen controls. This is just a guess,
not something actually based on studying the code behind the option.
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Thu, 09 Nov 2006 01:40:09

> I thought about that too, but it seemed to me
that there would be no
options are linked in
link the two options,
have saved me a lot

This is one of those cases where I shrug and say, "Why bother
indicating that link?" Suppose that when a user turns on Erase First,
LV recorded the current state of Synchronous Display and then turned on
Synchronous Display. When the user turns off Erase First, we restore
whatever the previous state of Synchronous Display was. When they look
at the Advanced popup menu, the Synchronous Display is checked and
grayed out. Add a note in the online help about what Synchronous
Display does that Erase First always turns it on (and why).  I
doubt that anyone would object to the setup.
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Thu, 09 Nov 2006 01:40:13

Regardless of the UI difficulties, it should be solved somehow. Therefore...
This was reported to R&D (# 436990J1) for further investigation.
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Thu, 09 Nov 2006 02:10:07

Argh!!! That's supposed to be an O in the CAR number, not a zero.
Stupid display font... Why doesn't everyone use British slashes/dots in
the middle of their zeros?!?!
This was reported to R&D (# 43699OJ1) for further investigation.
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by eaolso » Fri, 10 Nov 2006 03:10:08


So in my case, I was drawing different components of a Picture Control, with the "Erase First" option deselected...this means that new images are drawn "over" old images, and the old images remain in the Picture Control.  Well, if two draws happened in quick succession (which was possible since I was keying off of Mouse Move events to do some of my drawing), sometimes, the first draw would never happen, due to the Asynchronous Display behavior.  As a result, portions of my picture that needed to be there from the first draw would never appear.
I've never played around with Picture controls much, so I didn't realize (until now) that it consisted only of instructions for building an image rather than a buffered copy of the image itself. So I am guessing that the rendering into a raster image is happening in the UI thread? There doesn't seem to be any way to programatically render the instructions contained in the Picture wire itself. I'm guessing you could have achieved the same by using Picture to Pixmap and then Draw Flattened Pixmap to convert the raster image back to a Picture? I'm not sure if that would have had a bigger performance hit than turning off asynchronous display, however.
 
 
 

Darren's Weekly Nugget 11/06/2006

Post by Aristos Qu » Sun, 12 Nov 2006 09:40:07

The plan is that when a bug fix or upgrade is released that the public
forums of DevZone and LAVA will be searched for the key phrase (which
is why I have such exact wording). We'll check those CAR numbers and
post to the forums that the CAR has been fixed. This is all supposed to
be automated if possible.

This is something new that we're trying for the first time to try to
improve the feedback to customers. We'll see how it goes next release.