I use gif animations on the front panel as picture or on the controls. I experienced that some animations on LabView drops frames and the animation effect does not look well. Can somebody tell me the reason ?
In the attached zip file one can compare the difference. On the original gif the hammer hits the letter "U" but on the front panel the animation stops earlier and starts again.
I tested your animation and it appears to work just fine (DELL PII 350MHz portable W2K, it was the slowest I could find).
Although I notice that there was no time out on the event structure.
In the older versions of Labview, it was necessary to add a delay into loops to allow other processing such as screen updating and other background vi's to operate; about 20ms was usually enough. Put it in the loop rather than in the event structure.
You have not said anything about the hardware platform and with windows machines the performance of the display card directly affects the performance of the application!
To explain: - If you ask for a graphics bit blit operation (a graphics area draw operation), the application will be held untill the draw operation is complete. Thus if the display card is low performance or the hardware acceleration is switched off then the operating system and thus the CPU spend time moving around the actual graphics data rather than all the other stuff it should be doing.
Try the following: - Get a long text file and open it in Notepad List to the bottom Now set the Hardware acceleration to off (remember the setting) List to the top Notice the difference.... Don't forget to put it back again to whatever level it was
If the system was not dependent on the graphics update then the scroll time would be the same.
In conclusion I suggest that you check that the graphics hardware acceleration is set appropriately and remember that an errant application may not like alternative acceleration settings.
I have just generated a new gif file and can confirm that there appears to be a bug in Labview since version 6.1 (I think this means that it has always been there - we have just never noticed it before).
Yesterday I played around this problem. I gave serial numbers to all the frame and I saw that the last number (last frame) was missing during play. As a workaround I inserted an empty frame to the last position. Now it works.
But still there are other bugs. When I drag and drop the animation from the block diagram to the panel and /or vica-versa the animation behavior sometimes changes.
Additional the last frame duplication did not solve the problem. The last frame duplication generates an other not wanted effect. So finally an empty frame insertion is still the best workaround.
I think you should still check your display settings, but it is clear that not all is well with the GIF animation support from Labvew 6.1, 7.0 or 7.1.
I attach a demonstration GIF which counts.
One shows the last frame / digit being lost and the second animation includes a blank terminating frame of the same duration as the displayed frames. Also included are the GIF files such that anyone can test and work on the problem.
The P.C. I am currently working with maxes out with that many animations on one Labview panel. I have an 80% load and a 100% CPU load, so I would not expect the animation to be clear.
Nice demo for the problem though so perhaps NI will get around to fixing it.
I will do that. I am using 3 different PCs. One is my highend game PC at home. One is just for mailing working with docs, excel, web, etc, and one is for controlling external tools-testers. All are fully different hardware. All have LV 7.0. All show the same animation defects.
+ My LeCroy osci. I have not tested on that. But on that also LV7.0 🙂 is installed.