Draw picture slow down

[Walker34]

Hello

I represents a machine layout witth a picture indicator. 800px X 800px. There are a lot of dots on the picture. Additionnlay I want to represent a tool position on that image. Like a ironsight moving on the layout. so the user see where is the tool.

The moving ironsight produces a picture redraw (only if moving=>different image). Thats slows down massively my application. I made a lot of tests. The slow is really a redraw issue, not a calculation of items' position. For example, if I hide my picture beyond a big tab, there is no problem anymore.

I noticed that not only User-Interface thread is impacted, but the whole application.

But I found a workaround : use IMAQ image conversion! Like in this example :

https://forums.ni.com/t5/Example-Code/Convert-2D-LabVIEW-Picture-to-IMAQ-Image/ta-p/3511009

Con : I have to pay for each runtime licence.

My question is WHY? Why this picture rendering is not improved by NI?

[rolfk]

Because it is a general purpose drawing canvas, not a high speed optimized drawing tool. The drawing commands are simply concatenated to a binary stream of bytes and need to be parsed every time you redraw the image. That takes time.

Without seeing your actual code that is all we can tell you. Maybe you are doing things that are suboptimal or outright bad, but general questions get general answers.

In the same way you could ask why doesn't my car run with one gallon per 100 miles. There are cars out there who can do that, so why not my car? Well, it's all a question of investment. Rewriting the Image Control to be more performant costs time and effort, to solve a problem that is for 99% of the users a non-issue, since they don't use that control or are more than happy with what it does now. I'm sure you see the cost-benefit calculation in this and there are so many other areas that demand some attention too, while NI has not unlimited developer resources, so you can do the math.

[matt.baker]

Edit: rolfk beat me to it.

From what I remember, each operation of the picture functions adds it to the sequence instead of just updating the raw pixel data. Every additional operation causes the previous operations to be redrawn in sequence.

A way to overcome this is to periodically convert it to a Pixmap and then use 'Draw Flattened Pixmap' and an empty picture. In this way all of the operations have been flattened into raw pixel values.

 

Pre-computed pixels and new pixels

 

On my PC, if I run the above without the case structure, it causes the UI to hang when moving the image even after the VI has finished running (all the operations are still being performed in the IDE to display the image instead of a cached Pixmap).

[Walker34]

Thank you Rolf for your answer. That's true, but on my opinion, Labview should be improved. Allways and allways. When you see what Chrome or iOS is able to render, you want something better than an animated GIF in your software, and customer too. I mean, Picture control was probably good in 2008.

Thank you Matt, I kept trying after your intersting input. And finally I found! The issue is PEN width on 0. It is just a Labview bug. If you draw a circle width pen=0, then it is catastrophic! I also noticied that rectangles are faster rendered. I attached a VI as example. 

What I don't understand :  why draw_time is not impacted with Circle_pen=0, but UI is very slow.. ?

[rolfk]

I'm not sure what you try to show with that example. On my computer draw_time is ALWAYS flickering between 20 and mostly 21 when Page2 is active and mostly 21 and and sometimes 22 when Page1 is active. Considering that you have a 20 ms delay in sequence with the drawing code, I'm not sure what you expect otherwise to happen.

If you see a very different result it may actually have to do with bad graphics drivers in your computer.

As to always and always improving performance: Are you allowed by your boss to spend more time on a program when it already works, since there is this one function that could be made more performant by just spending a few weeks more work into it? If yes, congratulation you have a boss who does not care about money and you may be out of work soon as the business falters, if no .... well welcome to reality and normal business operation!

[wiebe@CARYA]

If you look into those picture control VIs, you'll notice that there's a lot of redundant opcodes pasted into it.

Most noticeable, most tools 'redraw' the brush, even if it doesn't change. That's a lot of CPU to make the string, and again to process it when drawing.

Make your own picture control tools if you want speed.

[matt.baker]

@rolfk, if you change the width to 0 it takes considerably longer to update the picture control on the UI

[rolfk]

How do you measure "considerably longer"? My eyes may be not the fastest but I don't really notice any difference on my computer between the two.

[matt.baker]

See the following screen capture. Not sure of the exact time, but it does appear to be a bug in LV. The UI actually hangs part way through the video when trying to change the width or stop it.

https://agdsystemsltd-my.sharepoint.com/:v:/g/personal/matt_baker_trafficgroup_technology/EbQGyTMrzF...

[wiebe@CARYA]

---

@matt.baker wrote:

See the following screen capture. Not sure of the exact time, but it does appear to be a bug in LV. The UI actually hangs part way through the video when trying to change the width or stop it.

https://agdsystemsltd-my.sharepoint.com/:v:/g/personal/matt_baker_trafficgroup_technology/EbQGyTMrzF...

---

I'm pretty sure it's a Windows GDI 'feature'.

The 2D picture control translates the opcodes to GDI...

I know there's a discussion about this somewhere (idea exchange IIRC), but can't find it ATM.