Jump to content

UI Window Move is slooow


Recommended Posts

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!

Link to comment

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.

Link to comment

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 by keyboard
Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.