History of Autonomous Graphing Widgets, is there a way to disable

[rolfk]

Sunchronous doesn't disable updates on the UI object at all, it only changes how the data transfer to and from the widget buffer is synchronized. In order to disable refresh updates on every property node (also note that combining multiple property node accesses in one by resizing the property node will also reduce the update time as LabVIEW will only refresh the control and context switch to UI thread per entire property node and not per item in that property node) you do need to enable the DeferUpdate property before doing a batch update to any UI element and disable it after! The serialization into the UI thread for property nodes will totally inhibit parallelization efforts to fold loop iterations as each property node has to wait for the UI thread anyhow.

[joeqsmith]

If you take the time to read again what I wrote, I never suggested disabling Synchronous would disable updates.   The objective was to send more information to the widgets before they update.   See below:

"In multithreaded systems, you can use the Advanced»Synchronous Display shortcut menu item to set whether to defer updates for controls and indicators. By default, controls and indicators use asynchronous displays, which means that after the execution system passes data to front panel controls and indicators, it can immediately continue execution. At some point thereafter, the user interface system notices that the control or indicator needs to be updated, and it redraws to show the new data. If the execution system attempts to update the control multiple times in rapid succession, you might not see some of the intervening updates.

In most applications, asynchronous displays significantly speed up execution without affecting what the user sees. For example, you can update a Boolean value hundreds of times in a second, which is more updates than the human eye can discern. Asynchronous displays permit the execution system to spend more time executing VIs, with updates automatically reduced to a slower rate by the user interface thread."

[BertMcMahan]

I don't believe you can do what you're trying to do (unfortunately) but you can make the graphs redraw so fast that it shouldn't matter.

Take your giant dataset, then downsample it by some factor. For example, if you have 1,000,000 data points, take every 1,000th point, and plot only that data. The user won't be able to see the difference anyway as you only have a few hundred pixels to show the data anyway.

When the user zooms in on the data, use the new indexes and grab a new set of 1,000 data points from your full data buffer, then plot that data.

For example: let's say you have 1,000,000 points, and send only 1.000 to the plot at a time. You'd be plotting point 0, 1,000, 2,000, etc. Say the user zooms in to the range of points 65,000 to 75,000. Now go back into your original data source, and grab point 65,000, 65,010, 65,020, and so on up through 75,000, and send that to the plot. Still just 1,000 points.

Your plot will still redraw automatically, BUT with only 1,000 data points in its buffer the redraw should be nearly instant, even if you have to redraw twice (once automatically, once after decimation).

You can still operate your "heavy math" on the full dataset, just store it in a shift register instead of a graph. Ideally, LabVIEW would do this automatically, but alas it doesn't.

Side note: Selecting your 1 point out of every 1,000 points requires some consideration, depending on your dataset. If it's showing some general trends, and specific mins and maxes aren't important, you can just take a point out of every 1,000. If you're looking for single-point peaks, you might want to take the *max* value out of every 1,000 points. You may also want to take the *average* of each 1,000 points. It just depends on the nature of your data. Some algorithms are a little quicker than others, so you might have to use some trial and error.

Edit: Also, it might help if you showed us some of your data. I just tried a quick sample with 10 million data points in a plot, and zooming wasn't exactly slow, so I'm confused at where exactly your slowdown is occurring. Are you sure it's the plot, not something else?

[rolfk]

But you made it appear as if Synchronous could be a way to speed up things. it isn’t, rather the opposite but it only applies to data updates through the terminal and local variables. In asynchronous mode you can write data to these terminals as fast as you want but LabVIEW will only update (redraw) the contral at most around 50 times per second (or less if you update with lower frequency). In synchronous mode LabVIEW will retrigger a redraw of the data after every update to the terminal or local variable. The result will be that you won’t be able to update the control data buffer arbitrarily fast anymore as the screen update has to wait for the UI thread to be available and then draw the new data to the screen before the next update can happen.

This has no influence on the update through property nodes even if you write to the Value property. Property node updates to frontpanel objects are always synchronous and have to wait for the UI thread no matter what. The Defer Update property can however disable the update to the frontpanel so that extra delay can be eliminated!

[drjdpowell]

I'm afraid I don't have an answer.  I also use data-reduction techniques (averaging or min/max) to get a few-thousand points to plot, and I just live with the momentary redisplay of the current reduction before the recalculed reduction is written.  I don't think it is possible to change the graph to stop this.  I a way I don't mind it, as it is important for the User to see immediate results from her actions, even if the data reduction is off momentarily.

[joeqsmith]

If you had taken the time to read my post again, you may have noted that I wrote disabled.  I am not sure how you get from disabled  to  "But you made it appear as if Synchronous could be a way to speed up things."

"Using the DeferPanelUpdates does help speed things up in some cases. For example, if I want to say deselect all of the plots. Doing the deselect in a tight loop, even with the Synchronous display disabled will still cause the graph to redraw for every call. In this case the defer will greatly speed up the process."

The 50 times per second update rate wouldn't concern me, it's the autonomous operation.  The time required to calculate new values and pass them to the graph is the amount of time that invalid data is being displayed.   The reason to work with smaller segments is not to get the graph to redraw faster but to allow for a faster calculation of the new data set.  

Not using the graph pallet and manually coding the range controls by other means is really the only way I see around it, which is what I have done in the past.

It's alright if you are still not understanding the problem.  It's pretty clear that there is still no way to get around it.