Help needed with dramatical bad performance of gauge controls

[PJM_Labview]

I think I may have an alternate approach for you. it may require quite a bit of coding, but it *might* work. Apparently, most of your gages on your panel are static (meaning, the scale does not dynamically change). You could get a screenshot of your dashboard static element, then dispaly them in a picture control in the background (or even as a background image). In another picture control sitting on top of the other, draw your needles for each gages.
Then again, on top, put you indicators. (not, you will have to also work on the color ramps).
I have done quite a bit of stuff with picture control, and while your application might be too "taxing" for it, I got pretty good results in the past). You could start experimenting by just drawing a line for a needle and see how it goes from there.

PJM

[unclebump]

Could you post as a 7.0 file. I'm curious to see what you are doing.

[Ben]

Good!

Someone else thinks the picture control is worth trying.

Keep the picture small as possible.

Ben

[M_Kunze]

First of all I want to thank you all for your help.

The most insteresting thing seams to be the overlapping issue.
I will invest a littel bit of time to check that problem.

While reading you relpys I found that some ppl. have not see
the configuration.

C3 1GHz
VIA Twister graphic
256 MB Memory
640 x 480 display with 32bit of colour

So please keep in mind that 'normal' desktops doesn't count.
I can have 20 and more updates on my 1900+ too. A C3 1GHz is
nearly comperable with 45% usage og a 1900+.

The point is:
If NI wants to go to the embedded market like VL PDA than
they have to learn that embedded processors must be cheap,
the systems have less performance than a deaktop PC and the
GUI must fullfill the expectations of a normal PC user.
If we feed the eye of a user with 2D GUIs like in LV PDA
than we will not win the price. We will earn fleer and
contumeliousness.

The GUI must work like a charm, must be outstanding, high
performant and look like state of the art or BETTER.
The things behinde the GUI are not interesing for the
customer. They all eat with there eyes.

With kind regards

Martin

[AnalogKid2DigitalMan]

Martin:

For future reference:

6. Get the Best Performance Possible in LabVIEW This application note describes factors affecting VI performance and offers techniques to help you obtain the best performance possible. Learn more about the Profile window, which displays VI execution time and memory usage data, and get more information about memory management in the LabVIEW dataflow model.


http://digital.ni.com/express.nsf/bycode/nn0505a06

[PJM_Labview]

Martin

As a follow up, here is a concept code using the picture control (LV7.1.1). My desktop machine is an old Athlon 1Ghz and it run smoothly.

Regards

PJM

[M_Kunze]

Dear members.

This is a posting with two parts.

Look at Page 1_3D_3.vi

And after that look at the next posting.

[M_Kunze]

Follow up on

Page 1_3D_3.vi

Look at Page 1_3D_4.vi too.

Page 1_3D_4.vi absobs just half of the CPU time
than Page 1_3D_3.vi.

The ONLY difference is that I have moved the RPM
out of the bounce or housing rect of the gauge.

So what we see here is not just overlapping of
parts or strings that reside into the gauge.
Its overlapping of the housing rect.

See that the blinking doesn't work poropperly
in Page 1_3D_4.vi too.

Its a real shame to see that.

In conclusion we can say that a good performing gauge
can't have a caption inside the housing rect, can't
have a digital value inside of the gauge and we can not
allow anything to be near the gauge.

DONT TOUCH ME.... Like a virgin isn't it?

NI PLEASE DO SOMETHING... SOLVE THIS PROBLEM PLEASE

Thanx in advance and with kind regards

Martin

[chilly_charly]

---

Martin Kunze wrote: In conclusion we can say that a good performing gauge
can't have a caption inside the housing rect...

---

There is something that you can do to improve (slightly) the situation : move the caption to the back (Toolbar > Move to back). As long as inert objects are under the gauge, there is no added time penality. This is not true however for the digital display...
Enjoy 😞 😞

[Ben]

Hi Martin,

I think we all agree that the poor performance of the guage control is due to over-lapping.

The below link

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=362#M362

contains links to a number of threads that have picture controls in the user interface.

The quick example that PJM posted is just a start to demo the speed.

The images of all of your guages is available using an invoke node get image.

My thought was...

1) Hide the digital displays and set the needle to a transparent color.

2) Get the image of each guage and position these images in a picture that you store in a shift register as the background image.

3) When it is time to update the FP insert the digital display were you need it and draw your needle.

Note:
Getting a 3-d effect is not that hard. all you need is one line of your needle to be a slightly different color from the rest of the needle.

I am only posting this because I did not want you to loose this project due to performance of the UI.

Just trying to help,

Ben