LabVIEW
Draw picture slow down
Solved!
@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.
I see in the video what you mean. However no such effect can be seen on my machine. It's a normal Dell Latitude Core i7 notebook, without fancy graphics hardware however. Very possible that specific video drivers have a problem somewhere.
As Wiebe said, the 2D Picture control simply is a stream of graphics commands. The format resembles very much the old Macintosh Quickdraw graphic primitives but is on each system translated to the underlying 2D graphics interface, for Windows this is the GDI API. And no, GDI is not that much different to Quickdraw that this translation would be very expensive. There are some notable differences such as that Quickdraw coordinates were actually located between the pixels whereas other graphic systems use the pixel coordinates, but that is nowadays more an anecdotal detail than that it has significant performance consequences. That translation requires at most some trivial coordinate translations and reordering of parameters for the drawing primitives, nothing more.
One problem with GDI can be that part of the GDI API is in fact for many functions a thin passthrough wrapper around the graphics driver for a specific video card. The GDI API manages the virtual screen and passes many of the actual drawing commands directly to the graphics driver with translated parameters from the virtual screen to the local monitor screen coordinates. Drivers can choose to not implement certain functions in which case GDI will emulate them with lower level primitives. It seems that something in your video driver is either badly implemented or even not at all.
Found the thread.
I'd on a (private) beta forum though: Simple graphics bring LV to it's knees - NI Community
Quoting (myself) from that thread:
It's actually a known GDI problem... Lines with width >1 are apparently drawn as polygons. A slowdown of >100 seems excessive, but I agree most likely it's all GDI.
I worked around this in the past by drawing multiple lines next to each other, although that takes some fiddling and is a somewhat silly workaround.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
Found the thread.
I'd on a (private) beta forum though: Simple graphics bring LV to it's knees - NI Community
Quoting (myself) from that thread:
It's actually a known GDI problem... Lines with width >1 are apparently drawn as polygons. A slowdown of >100 seems excessive, but I agree most likely it's all GDI.I worked around this in the past by drawing multiple lines next to each other, although that takes some fiddling and is a somewhat silly workaround.
But in this case however the problem seems to be for lines <1 (or 0) when drawing circles. And it seems to be dependent on the graphics drivers installed on a system. I see really no noticeable difference on my machine. They all three look equally fast similar to the example in the posted video when he showed it with pen = 1.
@rolfk wrote:
wiebe@CARYA wrote:
Found the thread.
I'd on a (private) beta forum though: Simple graphics bring LV to it's knees - NI Community
Quoting (myself) from that thread:
It's actually a known GDI problem... Lines with width >1 are apparently drawn as polygons. A slowdown of >100 seems excessive, but I agree most likely it's all GDI.I worked around this in the past by drawing multiple lines next to each other, although that takes some fiddling and is a somewhat silly workaround.
But in this case however the problem seems to be for lines <1 (or 0) when drawing circles. And it seems to be dependent on the graphics drivers installed on a system. I see really no noticeable difference on my machine. They all three look equally fast similar to the example in the posted video when he showed it with pen = 1.
Ah, missed that one.
If I turn on the picture control's asynchronous display, I do see a huge difference. Without the option, the draw time is stable at 22, with the option, width 0 jitters between <10 and > 50.
wiebe@CARYA wrote:
If I turn on the picture control's asynchronous display, I do see a huge difference. Without the option, the draw time is stable at 22, with the option, width 0 jitters between <10 and > 50.
Nothing on my machine! Stable at around 21 ms, independent of synchronpous or asynchronous display, or using pen 0 or 1 or even hide it altogether by switching to Page 2. Should I feel blessed with this machine?
@rolfk wrote:
wiebe@CARYA wrote:
If I turn on the picture control's asynchronous display, I do see a huge difference. Without the option, the draw time is stable at 22, with the option, width 0 jitters between <10 and > 50.
Nothing on my machine! Stable at around 21 ms, independent of synchronpous or asynchronous display, or using pen 0 or 1 or even hide it altogether by switching to Page 2. Should I feel blessed with this machine?
I moved the picture control out of the tab, and tried again, and couldn't reproduce it. Moved it back, and couldn't reproduce it. Then, without any specific reason, it was back.
If you want it faster, you can move all the 'static' things that needs to be drawn outside the for loop. You can build the picture control outside the loop, and concatenate the dynamic stuff to it, or draw the static stuff in a background picture control, and draw the dynamic stuff in a transparent overlay picture control (turn erase first back on).
All you probably need is a 800x800 2D array of U8 that has a fixed size and uses an intensity graph as indicator (you can hide the axed and resize it for the correct canvas size.)
Now all operations are just replacing array elements based on 2D index. Use a Z ramp of 256 color entries to map U8 values to pixel color. Everything operates fully in-place and with constant and small memory use.
You can do everything in the 2D data or you can even overlay simple shapes using the "plot images" tools if needed.
Here's a quick example showing the basic idea. As you can see, the loop time is constant (~20 microseconds), even after adding 1M+ points and it will never slow down!
As I said, create a colormap for the z axis that maps U8 values to 256 unique RGB colors. (not shown)
And here's how you would overlay the gun sight (approximated by a red circle for simplicity) or some other sprite. Make sure to only do this when the position changes, because it is somewhat expensive
Alternatively, you could add it to the data before display, without touching the data in the shift register. (not shown).
@altenbach wrote:
Alternatively, you could add it to the data before display, without touching the data in the shift register. (not shown).
Here's how that could look like (using 255 as reserved color):
(redraw is constant and about 40microseconds on my PC. Many things can be optimized further, of course)
