Render / Paint / Draw panel subset

[matt.baker]

Are there any functions to perform a background redraw (avoid explcitly displaying the redraw to the user) of only a subset of a panel and capture the image data? I'm thinking on the lines of increasing performance, hence just a subset redraw.

FP.Get Image performs a redraw in the background of the entire visble area and avoids updating the front panel which is part way there.

GObject.Get Image returns only the control image regardless of what's behind or in front of it.

Also, are there any events available to me that are fired when the front panel is requested to redraw or redraw initiated?

Or a way to override the redraw method?

This is all in relation to custom controls that support transparency.

I was impressed with the smoothness of the open GDS viewer that uses a single picture control to paint custom controls and respond to mouse over events etc. and would like to do something similar, but in combination with the built-in LabVIEW controls as well (render over the top of them etc.).

Thanks

[Hooovahh]

The only thing like that I can think of is to use the Defer Front Panel Updates property on a VI.  This will tell the VI not to redraw the UI until you tell it by undefering the update at which point all changes from the time the defer was commanded, will be drawn at once.

https://decibel.ni.com/content/docs/DOC-4519

This is on a whole VI at once, not subsets of it.  You could probably get trickly and use subpanels to load VIs which get updated or not as well.

[matt.baker]

Thanks. I did try using defer updates to make it less choppy when hiding controls, redrawing and then making them visble again.

The image capture takes around 65 ms on average for an area of about 1800 x 900 on my PC when built as an executable with execution set to Highest priority.

Not very usable for smooth updates 😞

There's probably a way to use the LabVIEW.exe functions to somhow create new pure controls (IDraw interface etc), but these aren't documented (for a good reason I guess).

If only it was posible to inherit from the GObject class and override the draw/paint methods.

[tst]

My understanding is that LV basically does all of its drawing on its own and that it makes limited use of hardware acceleration, both to maintain compatibility between platforms. You can see this, for instance, if you use a .NET control, which is drawn as a child window. This effectively means that the your use case wasn't planned for and isn't liable to work well. You can do some playing around and customizing and get nice results, but it probably won't be as nice as you like.

A couple of resources which might be of interest:

https://decibel.ni.com/content/groups/ui

https://lavag.org/topic/19611-utf-8-text-svg-images-inheritable-gui-components-dynamically-composed-...

[Ben]

post # 35 in this thread as well as some of the other links may be of interest.

The linked thread from that post has code that uses a picture control to display a bunch of images, give you a preview of the animation when you mouse over and will copy the associated link to your clip-board if you click on an image.

I have alos grabbed images of LV controls ahead of time, cached them and then put a numeric value over-top of the LV contro limage to give the impresion of a live update.

Re: Defer FP-Update

It forces a redrawn when set and then allows updaes latter. It is most useful when you have alot of graphic updates happening and you want to speed things up.

Ben

[matt.baker]

Thanks for the info and links. LQ Widgets looks promising at first glance.

I also had a look at http://forums.ni.com/t5/LabVIEW/A-more-successful-experiment-in-creating-compositable-user/m-p/12768... mentioned in the LQ WIdget thread.

The redraw seems responsive enough when using virtual controls in a single picture control.

Maybe that will be the way to go: No LV controls and just a single picture control/ other container. I supose an XControl could be created to give edit time creation and movement of the virtual controls.

There's always going to be that trade off between customisation and complicated diagrams when using it.