LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Drawing graphs in LabView - CPU load

> In my data acquisition application a user can open several windows
> with an XY graph in each one. The CPU load is high (~ about 80-100%)
> and quite a bit of it is due to the GUI activity. If one just
> minimizes the GUI windows - the CPU load drops some 20-30%, so I guess
> that the resources are spent on the rendering. Important: I DO NOT use
> the "synchronous display" option.
>
> I wonder if a display adapter with some kind of rendering
> acceleration could help and perform some work that CPU does now. If
> so, what type of acceleration ? Which adapters support it ?


You don't mention what the requirements are. You have already done some
good benchmarking to determine that the graphs are responsible for about
half of the load. Write a simple small VI where you have similar graphs
with random or computed data written to them. Now, with the task
manager showing CPU usage, experiment with the graph appearance.

The default graphs are pretty fast, but they do have autoscaling on.
For graphs with lots of data, it takes probably an extra 5 to 10 percent
to swoop through the data looking for the min and max. If you don't
need it, turn it off. The grids are on by default on many of the
graphs. Turning them off will get rid of some drawing, not huge, but
maybe another 5 to 10 percent. Size matters. Play with the size of
your graphs and you will see that a portion of the display time, the
rectangle erase is sensitive to the area of the black portion of the graph.

Another thing to note is that text is expensive to draw. A graph has
lots of text on it. If autoscaling is off, no big deal, but if on,
periodically, lots of text will need to be redrawn.

You should experiment with things like deferred panel updates, but if
you are not setting lots of properties or having overlapped graphs, this
will probably slow down rather than speed up.

Finally, after doing a bit of this, you will get a feel for how often
you can afford to redraw the graphs. Is 10 fps good enough, or do the
clients require 20fps -- that takes twice the CPU time. More
importantly, this benchmark program will help you compare different
video settings and cards. Lots of people have mentioned moving to 16
bits. Here is a bit longer explanation. If you are using classic or
dialog controls, 8 bit display settings are likely up to half the cost
of running at 16 bit, and there are cards around where 24 is the same
speed or faster than 16 bit. So, my advice is to build something you
can time, or open an example, and change the video settings to tune your
setup.

If you want to try additional video cards, LV uses the 2D GDI functions
and a SW based rendering engine with lots of caching. The high end 3D
cards will not be that much better than a good 2D video card. That
said, it changes every six months, and people that have two monitors on
two different video cards will often have a 4x to 5x speed difference
depending on where they have their window drawing.

Finally, be aware that some of the 3D controls take longer to draw,
overlapped controls take longer, and transparent controls take longer.
Experiment and you will quickly find out how to control it.

Greg McKaskle
Message 11 of 11
(937 Views)