keyboard Posted May 13, 2010 Report Share Posted May 13, 2010 Hi all, I have a situation where UI window for application built with LV2009, takes a long time to move - i.e simple operation to reposition UI window on the monitor takes upwards of 2 seconds, and slows whole machine down during that time (Windows XP Pro Pl Dual Celeron as well as on Win7). Any ideas? (my guess is that it might have to do something with hardware acceleration for display....just a wild guess). Code doesn't do anything really fancy. Only thing I can think of is that Google Earth is called via ActiveX - it gets ref. from Automation Open, and eventually displays Google Earths "map" inside LV using IWebBrowser.... Thanks! Quote Link to comment
ShaunR Posted May 13, 2010 Report Share Posted May 13, 2010 Hi all, Google Earth is called via ActiveX - it gets ref. from Automation Open, and eventually displays Google Earths "map" inside LV using IWebBrowser.... Thanks! Yep. That would do it. The key point being "ActiveX". You can try to make sure the open ref is only executed once (when the vi is started...ie outside any loops) and hope that the "stall" isn't from the get method. Quote Link to comment
asbo Posted May 13, 2010 Report Share Posted May 13, 2010 What's worse is that you're laying through two different ActiveX automations - the one for Google Earth, and then the web browser one. You might look into finding a way to implement the Google Earth ActiveX directly. Quote Link to comment
keyboard Posted May 14, 2010 Author Report Share Posted May 14, 2010 (edited) asbo - you are right there are two ActiveX automation calls. update: So it turns out ( so far ) that problem was with couple of data indicators on the front panel. As soon as I removed them problem went away. There wasn't anything special about those indicators, they were around some dials on the tabbed panel. Not sure how/why that would influence strange window behavior, but it did.... Edited May 14, 2010 by keyboard Quote Link to comment
Ton Plomp Posted May 15, 2010 Report Share Posted May 15, 2010 asbo - you are right there are two ActiveX automation calls. update: So it turns out ( so far ) that problem was with couple of data indicators on the front panel. As soon as I removed them problem went away. There wasn't anything special about those indicators, they were around some dials on the tabbed panel. Not sure how/why that would influence strange window behavior, but it did.... What style were those indicators? 3D (modern) and were they overlaying other indicators/controls/GUI elements? I think the latter is most likely the cause of your slowdown. Ton Quote Link to comment
keyboard Posted May 15, 2010 Author Report Share Posted May 15, 2010 What style were those indicators? 3D (modern) and were they overlaying other indicators/controls/GUI elements? I think the latter is most likely the cause of your slowdown. Ton That's exactly situation overlay and type of indicators used ! But why? Is that known bug? Quote Link to comment
Rolf Kalbermatter Posted May 17, 2010 Report Share Posted May 17, 2010 That's exactly situation overlay and type of indicators used ! But why? Is that known bug? Bug?? Well, I would rather call it a limitation of the used underlying MESA library for rendering the Alpha shading of the modern controls. Quote Link to comment
Wire Warrior Posted May 18, 2010 Report Share Posted May 18, 2010 NI talks about this particular issue in the LabVIEW Performance class. When you overlay controls, the LabVIEW execution engine must "redraw" ALL overlaid controls every time either of the controls are updated. It the situation you mentioned I would suspect one or both of the overlaid controls were updated frequently. If so, then the Google Earth ActiveX would be executed at the same frequency. I can see where that might chew up some serious processor cycles. If you could move those controls to a different area of the UI, you would likely see an improvement in the performance. Jason Quote Link to comment
Cat Posted May 19, 2010 Report Share Posted May 19, 2010 NI talks about this particular issue in the LabVIEW Performance class. When you overlay controls, the LabVIEW execution engine must "redraw" ALL overlaid controls every time either of the controls are updated. Is this true for *all* controls or just "modern" controls? I'm in the midst of overlaying 18 graphs/charts with update rates down to 125 ms where various combinations of 1/2/4 plots will be on top and everything else hidden underneath. I posted about it awhile back. Unfortunately, none of the approaches suggested worked well for my application so I'm back to stacking them all. Everything resizes great, but I'm afraid when I finally hit the run button it's all going to come crashing to a halt. Quote Link to comment
Wire Warrior Posted May 19, 2010 Report Share Posted May 19, 2010 Is this true for *all* controls or just "modern" controls? Yes it is true for all controls. Of course some require processing that others. The important component when overlaying is the rate of update. How often do your graphs update? Once a data run would likely not be a noticeable issue. At 1000 Hz it maybe an issue. Probably the best thing to do would be to test your system as early in the build as you can and measure the performance time. Jason Quote Link to comment
Cat Posted May 20, 2010 Report Share Posted May 20, 2010 Probably the best thing to do would be to test your system as early in the build as you can and measure the performance time. Thanks for the info. I plan on hitting the run button today. Results over in the link I cited above... Quote Link to comment
Rolf Kalbermatter Posted May 20, 2010 Report Share Posted May 20, 2010 Is this true for *all* controls or just "modern" controls? A full redraw is required for any overlaid control. But modern controls have extra overhead since they all use alpha shading which is a rather costly screen update operation. So you can say overlaying controls that update frequently is always a rather bad idea, but if it involves "modern" controls it is even an order of magnitude worse. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.