LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

picture flickering

Hallo all,

I'm working on a small research project on motion learning in humans.
What I'm trying to do is a simple 'game' where the player has to try to follow a track moving on the screen with the cursor.
The player move the cursor acting with his forefinger on a slider connected to a DAQ card.

I'm having troubles with the track display. I'm not able to avoid some disturbing flickering effect.
I've found an old discussion (2002) with a similar problem but with no solution.
May be in this time a solution have been found or some new features of  LV have solved this issue.

I attach a simple example that on my laptop generate the flickering.
My track is an array of points that I draw on the screen with DrawMultiplesLines.vi
In this example I use sine function do generate the track, in the real application we have more complex tracks.

thank you

Gianpiero

LV 8.5





Message Edited by htdev on 12-13-2007 05:32 AM

Message Edited by htdev on 12-13-2007 05:34 AM
0 Kudos
Message 1 of 13
(6,267 Views)
Right click on the picture, Advanced, Synchronous Display

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 2 of 13
(6,244 Views)
The most important setting would be "right-click...advanced...Smooth updates".
 
from the LabVIEW help:
When LabVIEW updates an object with smooth updates off, it erases the contents of the object and draws the new value, which results in a noticeable flicker. Using smooth updates avoids the flicker that erasing and drawing causes.
 
I am not sure if synchronous display (as suggested above) would really help, it just forces a front panel update of the indicator with every write to the indicator terminal. This could significantly slow down your code.
 
from the LabVIEW help:
By default, controls and indicators use asynchronous displays, which means that after the execution system passes data to front panel controls and indicators, it can immediately continue execution. At some point thereafter, the user interface system notices that the control or indicator needs to be updated, and it redraws to show the new data. If the execution system attempts to update the control multiple times in rapid succession, you might not see some of the intervening updates.

In most applications, asynchronous displays significantly speed up execution without affecting what the user sees. For example, you can update a Boolean value hundreds of times in a second, which is more updates than the human eye can discern. Asynchronous displays permit the execution system to spend more time executing VIs, with updates automatically reduced to a slower rate by the user interface thread.

Message 3 of 13
(6,228 Views)
Thank you for your answers but in my experience and also in the case of the discussion mentioned above neither Smooth Updates nor Syncronous Updates helps a lot.

Did you try my example vi ?

gianpiero
0 Kudos
Message 4 of 13
(6,224 Views)

I think I see what you are talking about.  But it is very subtle.  Synchronous, vs. asynchronous vs. smooth updates settings have a small effect.

If you are seeing what I'm seeing, I think it is normal.  Windows can only redraw a screen so fast.  It's like when you scroll quickly and a long distance in a web browser or excel, you see some breaks and disjoints in the screen because you are basically seeing the new image being redrawn on top of the old image.

0 Kudos
Message 5 of 13
(6,202 Views)
A solution would be to build a back buffering machanism. Make 2 picture
controls. Draw in one hidden control, display the other. Always show the
hidden one before hiding the other. Works like a charm

You might even consider using the 3d picture control. This control has much
better handling of the drawing/buffer swapping. It will be a bit more
difficult to make, but with proper choise of sub vi's it will look almost
the same.

Can't open your VI (need <8.2.1), and I can reproduce the problem, but am
not sure if it is the exact problem...

Regards,

Wiebe.


0 Kudos
Message 6 of 13
(6,177 Views)
Wiebe,

thank you for your suggestions,
I tried the double buffering, but also hiding and displaing quickly the pictures gives some bad deffect.
I attach the example exported in LV 8.0 file format . Maybe you can give it a try and see how it looks on your machine.

regards

gianpiero


0 Kudos
Message 7 of 13
(6,090 Views)
gianpiero,

I tried your VI on my Mac (OS X 10.4.11 and LV 8.5). At refresh rates close to the screen refresh rate I find that synchronous display is noticeably smoother than asynchronous. At slower rates I cannot see any difference because the refresh itself is slow enough to be visible. Smooth updates do not seem to make much difference.

I cleaned up the diagram a bit. The sequence structure is eliminated by use of dataflow. I changed representation of constants and controls to eliminate all coercion dots inside the while loop. I also moved all calculations which do not change while the loop is running outside. These changes may not make much difference in this VI, but in your larger program they could save a bit of time and that might make a difference.

Lynn
0 Kudos
Message 8 of 13
(6,078 Views)
Seems to me that it's the eye that is fooled here. At least to some account,
that is the cause of the flickering.

The jump between two frames is so big, it appears to the eye (or brain) as
flickering. If you put the "6" in the second frame's for loop to 1, you'll
have just as many points, but far less flickering. You even have less
flickering if you concatenate the daya array 3-6 times!

I'll attach something soon.

Wiebe.


0 Kudos
Message 9 of 13
(6,035 Views)
This runs smooth on my PC (LV 8.2.1):
 
 
0 Kudos
Message 10 of 13
(6,031 Views)