UI Window Move is slooow

[keyboard]

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!

[ShaunR]

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.

[asbo]

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.

[keyboard]

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

[Ton Plomp]

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

[keyboard]

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?

[Rolf Kalbermatter]

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.

[Wire Warrior]

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

[Cat]

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.

[Wire Warrior]

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

[Cat]

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...

[Rolf Kalbermatter]

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.