Resize asynchronously launched window with XY graph crashes

[cerebus]

I have a graphing program I created as a LabView executable.  It receives incoming data over TCP and displays it in an asynchronously launched vi that contains an XY graph control.

After putting a large amount of data in (5 plots at 259,200 points each) I attempt to resize the vi window.  The XY graph control scales with the window.  However when this control is near full I get the following error message (see attachment).

DAbort 0x89B93EF0%3A bad image in ValidateImage

This executable was created with LabVIEW 2011.  The program CPU usage is ~200MB, 15% CPU, with ~ 600 GDI Objects (according to task manager).  THe GDI objects do not appear to be increasing (except when I'm interacting with the vi they temporarily do).

Does anyone have any suggestions on things I could try to fix this problem?  I am unfortunately unable to share the code.  I could probably do screen shots of specific areas if someone could guide me where to look.

I am open to any and all suggestions.

[cerebus]

As an FYI, if I start with a fully populated graph of points... this crash does not occur, it's when I add one point at a time that this issue occurs...

If that helps.

[mikeporter]

I would say the plot has too much data in it. Try decimating the data before plotting. Unless you have a monitor the size of a jumbotron you are not going to see all 259,200 data points for even 1 plot...

Mike...

[cerebus]

having the full buffer has certain advantages such as allowing the user to zoom or pan through it freely. I can try reducing the points by decimation but it has no problem running 10 times as many points so I suspect a different issue is at play.

[Blokk]

---

@cerebus wrote:
having the full buffer has certain advantages such as allowing the user to zoom or pan through it freely. I can try reducing the points by decimation but it has no problem running 10 times as many points so I suspect a different issue is at play.

---

In the past I always did the same, let the Graph do the decimation. The painful part of this is the slowness and performance problems I had to always face, so in the end I just programmed an automatized decimation. I store all the data in FGV, and if the user requests more points to plot on the Graph, than its horizontal pixel size (there is property node for this value), I decimate the data accordingly.

The downside of this technique is the additional work, but when it works, you just have a fast and compact Graphing application. I did not have the energy to program a zoom function (as you want more features, complexity can really go havoc 😄 ), but in my case the user only required to be able to set a start and end point in time to plot any intervals of the whole data...

The good thing in the above algorithm is that if you make it generic enough, you can use it also in your future LabVIEW projects.

When I had to deal with these issues, I have found this example too:

https://decibel.ni.com/content/docs/DOC-13819

I have found it buggy in my case (it did not handle larger data sets good), but it is still very interesting approach.