Thanks Rob.

I kept using the CategoryDateTimeXAxis because I cannot guarantee all the points will be equally spaced. It just made my life a little easier if it took care of the spacing for me. I just wish I could tell it to not sort as an optional optimization.

I look forward to anything I can do to optimize the EEG chart as well. I have a C++ guy I work with that is giving me a lot of flack about .NET graphing performance... :)

Hi Valerie,

I just verified that the collection objects do not implement INotifyPropertyChanged so they cannot be firing off any events. Also, I am replacing the collection element, not updating a property of the object, so it shouldn't matter if they did implement that interface right?

I have actually been working on this chart performance for some time. I have implemented a few other chart controls to see if I can get better performance and so far only one has met my expectations (LightningChart). It uses about half the CPU to draw the same graph as Infragistics but as I have started using other Infragistics controls I don't want to include another 3rd party control into our product. I am still hoping we can find a more efficient way to create a sweeping EEG that doesn't kill a tablet.

Thanks,

Mike

Hi Mike,

I was under the impression that you were just updating the data points by updating their values rather than replacing them, based on your initial description of your implementation.  Since you are just replacing the items, INotifyPropertyChanged will have no bearing on this.

While I don't have an EEG example, our engineers have given me code for an EKG and I imagine that the update strategy would be similar so I'm throwing a sample together.  Out of curiosity, what kind of tablet are you using?  And just to make sure, as I have seen other posts by you on the Silverlight forums, this is for WPF correct?  I should have asked this initially.

Sorry for the confusion.

This is the code I use to update the collection:

waveForm.WaveData.SuspendCollectionChangeNotification();
//_logger.Info(String.Format("Enter OC lock - UpdateWaveFormCollections - {0}", waveForm.WaveChannelName));
// add all the points from the buffer to the data list that are older than the updated LastDisplayedTimeStamp
WaveFormDataPoint data;
while (waveForm.WaveDataBuffer.Count > 0
&& waveForm.WaveDataBuffer.TryPeek(out data)
&& data != null
&& data.TimeStamp < waveForm.LastDisplayedTimeStamp)
{
   if (waveForm.CurrentPosition >= collectionSize)
   {
      waveForm.CurrentPosition = 0;
   }
   WaveFormDataPoint queueitem;
   if (waveForm.WaveDataBuffer.TryDequeue(out queueitem))
   {
      waveForm.WaveData[waveForm.CurrentPosition] = queueitem;
      waveForm.CurrentPosition++;
   }
}

// Add the moving space
if (waveForm.WaveDataBuffer.Count > 0)
{
   int spacesize = (int)(0.5 / waveForm.SecondsBetweenPoints); // half second. quan of samples to use for moving space
   int last = 0;
   for (int p = 0; p < spacesize; p++)
   {
      var emptywavedata =
         new WaveFormDataPoint
         {
            TimeStamp = waveForm.LastDisplayedTimeStamp.AddSeconds(waveForm.SecondsBetweenPoints * p),
            Value = float.NaN
         };
      if (waveForm.CurrentPosition + p >= collectionSize)
      {
         waveForm.WaveData[p - last] = emptywavedata;
      }
      else
      {
         waveForm.WaveData[waveForm.CurrentPosition + p] = emptywavedata;
         last = p;
      }
}

// If the control is not visible the do not notify
// the observable collection of changes
if (IsVisible)
{
   waveForm.WaveData.NotifyChanges();
}

EKG is perfect as well. Just need a really efficient method to plot several graphs at 500Hz.

This is a crappy (not all that bad just annoyed with it right now) little Windows tablet using an Atom N2600 @ 1.6GHz

Hi Mike,

I put together a sample that used our developers data and it turns out this looks more like an EEG than an EKG.  Looking at your update code though, I believe we're doing it similarly, except for the while loop and the wave data buffer part.  Although in my case I'm not pulling datapoints from a queue to override the data source, but I'm instantiating new data points entirely.  It shouldn't matter though, yours may be more memory efficient that way.

One thing I notice in our developers sample though, is that the chart looks like a normal EEG without needing to use 4000 data points.  Now I don't know what your EEG looks like with 4000 data points but when I compare my sample with pictures I see on the internet, it looks pretty close.  I attached the sample so you can take a look.  If I bump up the amount of data points to 4000, I do notice a jump in my cpu usage.  Task Manager isn't really the best tool to use for this but on my laptop it was staying around 13% with 4000 data points.  I then tried it out on a Surface Pro tablet (i5 1.7GHz so a bit more powerful than yours) and Task Manager showed between 30 and 40% cpu usage.  From these tests I definitely can see how it could be worse on your tablet.

My conclusion from all of this is that I don't think there is anything wrong with the way you are updating the data.  I think it just comes down to the chart itself trying to render 4000 constantly changing data points on a tablet.  For the tablet, you may need to try playing with the Resolution property on the LineSeries to try and cut down on the number of geometry that is rendered.  Or you'll have to see if you can get away with lowering the data point count so the chart doesn't have as much to render.

empty

Hello Mike,

Thanks for clarifying.  The information in this thread should prove useful to the community.

Let me know if you have any further questions.

We have a tablet with an Intel N2600 Atom processor so it is very low power. I believe it has GMA 3600 graphics chip.

Hi Mike,

Interesting.  I'm curious as to what kind of graphics processor the tablet has.  I haven't really seen cases where software rendering is actually better than hardware rendering but if the graphics processor is just that bad then I guess it could give you a boost.  I never even thought about considering that.  Nice find!

I believe I understand. Thanks.

On my desktop I do see acceptable performance. I have been working with the resolution and decreasing the number of points I plot but I do not see significant gains in performance vs. the loss of accuracy in the graph. I did find out that if I force software rendering mode I get a nice performance boost on the tablet so this may make the app acceptable.

Thanks for the help.

Mike