LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding points to a picture without redrawing previous points

In my application, I need to dynamically display scatterplots containing a large number (thousands to millions) of points, to which more points are added continuously. These points are not evenly distributed, and many overlap, so that only a fraction of the points are actually visible in the final display. Ideally, I would like to control the color of each point, so I am presently using a picture, to which I incrementally add points using Draw Point.vi After days of confusion about why my application was running so slowly, I came to the realization that the picture data type merely contains a list of all of the graphical objects in the picture. Thus, if I have a thousand points all drawn to the same small region of the picture, when I update the display, each of these points is individually added to the display, causing the speed of the update to decrease linearly with the number of points.

The best solution to this problem seems to be using some sort of bitmap instead of a picture data structure, so that overlapping points are only represented once. However, I figure that each picture is approximately 200x200 pixels at 32 bits per pixel, or a total of 160 kbytes per picture. Even if I operate directly on pixmaps instead of pictures, I'm afraid that each time I change the value of one of the bytes in the pixmap, LabVIEW is going to make a copy of the entire pixmap. I need to update the display 5-10 times per second, and because of the other computational constraints of my program, I only have 1-5 milliseconds in which to perform each update. I find it hard to believe that LabVIEW can make a copy of a 160 kbyte image in on the order of 1 millisecond (this would correspond to manipulating about 160 megabytes of data per second).

Is there any way to manipulate the data in a data structure in-place without making a copy? Alternatively, is it possible to directly manipulate the underlying data structure into which a picture is converted when it is displayed on the screen? That is, if I could directly write into particular locations of the frame buffer from which the screen is drawn, I could use it to accumulate the points in my scatterplot without explicitly redrawing each point every time I want to update the display.

Thanks for your help.

Jason
Jason Rolfe
0 Kudos
Message 1 of 5
(3,197 Views)
Jason;

I think you need to use shift registers. Check out the following example:

Drawing a Circle with the Mouse in LabVIEW

Regards;
Enrique
www.visecurity.com
www.vartortech.com
0 Kudos
Message 2 of 5
(3,197 Views)
Enrique -

I'm already using a picture data type with shift registers to incrementally add points. This is not a viable solution because, as you will see if you delve into the the picture function VIs, pictures merely consist of a series of concatenated strings which describe how to construct the desired image. Thus, a picture which contains thousands or millions of overlapping points explictly contains and must draw each and every one of those points, even if they only cover a small number of pixels. It is these overlapping points of a picture built using a shift register, and the slow speed at which they are rendered when the composite picture is displayed via a front-panel picture indicator, which is slowing down my application to an unworkable degre
e. Please refer to my original posting for a complete description of the problem.

Jason
Jason Rolfe
0 Kudos
Message 3 of 5
(3,197 Views)
Rolfe wrote:

> I'm already using a picture data type with shift registers to
> incrementally add points. This is not a viable solution because, as
> you will see if you delve into the the picture function VIs, pictures
> merely consist of a series of concatenated strings which describe how
> to construct the desired image. Thus, a picture which contains
> thousands or millions of overlapping points explictly contains and
> must draw each and every one of those points, even if they only cover
> a small number of pixels. It is these overlapping points of a picture
> built using a shift register, and the slow speed at which they are
> rendered when the composite picture is displayed via a front-panel
> picture indicator, which is slowing down my a
pplication to an
> unworkable degree. Please refer to my original posting for a complete
> description of the problem.

The Picture Control has an update mode. A Property node "Erase First"
allows you to set if the Control should erase always, never or just this
single time. The pop-up for the Picture Control only has a checkmark for
this option mean ing erase always of never for obvious reasons. You can
set the Control to never clear its data, and then just adding the newly
added points (draw primitives) to the Picture Control will draw over all
previously painted data if necessary not cleaning the internal bitmap at
all before doing so.

Then whenever you decide you want to start completely new you execute
the Property Node "Erase First:Erase Once now".

Rolf Kalbermatter
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 5
(3,197 Views)
Wow! What a difference. The time required to add a point to a picture with Erase First disabled is less than 1/100 the time required to redraw the picture from scratch if there are a lot of points (thousands) in the picture.

As a side note for any others who have a similar problem, I've found that elements of a flattened pixmap (a 1-D array of U8 which encode the RGB values of successive pixels of the image in raster order) can be changed suprisingly quickly using Replace Array Subset. I suspect that, if the VI is written so that the unchanged copy of the pixmap is never used again, LabVIEW is smart and actually makes the change in place rather than making a copy of the old pixmap in the process of effecting the change. However, it
takes some time to flatten an unflattened pixmap, so if speed is critical its best to work with flattened pixmaps directly. Drawing a flattened pixmap is pretty fast (using Draw Flattened Pixmap), and the time required to display the resulting picutre in a picture control is almost certainly independent of the content of the picture.

Jason
Jason Rolfe
0 Kudos
Message 5 of 5
(3,197 Views)