Pre loader

RenderPriority Immediate is not Immediate

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

0
0

Hi,

As part of our evaluation of SciChart a very important point for us is responsiveness, as I mentioned in another post

A point that is causing concerns is that we need to update the UI in a reliable, synchronous, non-deferred way, even if this means blocking the user input. So for us the only method that works is to user RenderPriority.Immediate.

Unfortunately it seems that for complex data were the rendering starts to struggle SciChart just skips updates to the view. We tried to manually force the update using code, but we have the same problem described here (i.e. RenderPriority.Manual does not work).

So, how can we be sure that the UI gets updated every single time we update a DataSeries, regardless of load, user input, whatever?

Version
5.4
  • Lorenzo Dematte
    One more bit of information: we are hosting WPF inside a MFC application. Could it be the MFC – WPF interaction that gets in the way? How?
  • You must to post comments
0
0

Nothing on this point? It is fundamental for us knowing reliably how the library behaves under pressure (constant updates)

  • You must to post comments
0
0

Good morning Lorenzo,

My apologies that no-one has answered this! I can tell you exactly how the different render priorities on SciChartSurface.RenderPriority work and what they are for.

  1. RenderPriority.Immediate means every single update to the chart (data changed, property changed) triggers a redraw immediately. It is (contrary to what you’ve said), immediate. There is no throttling or delay. This RenderPriority mode is awful for performance however, as it is possible to update the data thousands or millions of times per second, and forcing an entire render pass each time is not good practice.

  2. RenderPriority.Normal uses a 60 FPS CompositionTarget.Rendering event to throttle rendering. This is the default mode. In this mode, every data-change you make, property change to the chart is queued. Every 1/60s we accumulate all the queued changes and draw once to the screen. Unless your users have super-human vision, they shouldn’t see changes made faster than 1/60th of a second. This RenderPriority results in an extremely good balance of performance and responsiveness and is used in most applications.

  3. RenderPriority.Low was created to tackle the problems that can rarely occur with RenderPriority.Normal. This mode puts the priority of drawing slightly below the DataBinding in the UI Thread in WPF. This way the UI will never lock up or stutter if the chart is pushing your machine to the limit. We recommend setting this value unless you are experiencing problems in the UI such as buttons or UIElements not responding while the chart is heavily updated.

  4. It is also possible to set the property SciChartSurface.MaxFrameRate if you wish to increase the maximum FPS under .Normal mode. For example, setting to 100 increases the max frame-rate of throttled drawing to 100FPS.

So my answer to your question ‘how can we be sure that the UI gets updated every single time we update a DataSeries, regardless of load, user input, whatever?’ is as follows

Use RenderPriority.Immediate

This will update the chart every time you change anything. It will also result in awful performance and is not recommended. We recommend using RenderPriority.Normal. Anything else is going to be counter productive in your application.

If you have more questions or require more information, please let me know! You can email me directly (I am the tech lead of SciChart wpf) at my-name @scichart.com, or use the contact page at http://www.scichart.com/contact-us to get a rapid response from technical sales.

Best regards,
Andrew

  • Lorenzo Dematte
    Good morning Andrew, thank you for your detailed answer. As I mentioned in my comment, we were not 100% sure why we were seeing the delay in rendering and we wanted to double check. It seems then the culprit is somewhere near the MFC/Winforms to WPF interaction. Have you ever seen something similar?
  • Andrew Burnett-Thompson
    Hi Lorenzo, will answer below, one second
  • You must to post comments
0
0

Hi Lorenzo,

Good morning Andrew, thank you for your detailed answer. As I mentioned in my comment, we were not 100% sure why we were seeing the delay in rendering and we wanted to double check. It seems then the culprit is somewhere near the MFC/Winforms to WPF interaction. Have you ever seen something similar?

No, we haven’t. You’re using MFC or WinForms? I do know that all three have their own message pumps which can have odd interactions (that is Microsoft for you). Also there are some multi threaded considerations here. The code path for RenderPriority.Immediate is very simple, I can share the code for you.

In our chart any property changed anywhere (e.g. DataSeries update, Axis.Foreground color, a Fontstyle, width, height – anything) causes SciChartSurface.InvalidateElement() to be called. This code is as follows.

    /// <summary>
    /// Asynchronously requests that the element redraws itself plus children.
    /// Will be ignored if the element is ISuspendable and currently IsSuspended (within a SuspendUpdates/ResumeUpdates call)
    /// </summary>
    public virtual void InvalidateElement()
    {
        if (IsSuspended)
        {
            SciChartDebugLogger.Instance.WriteLine(
                "SciChartSurface.IsSuspended=true. Ignoring InvalidateElement() call");
            return;
        }

        if (RenderPriority == RenderPriority.Immediate)
        {
            // No CompositionTargetRendering event when running SciChart from tests
            Services.GetService<IDispatcherFacade>().BeginInvokeIfRequired(DoDrawingLoop, DispatchPriority.Normal);
            return;
        }

        // Else, do throttled draw 
    }

You can see above here DoDrawingLoop is synchronous unless your update is on a background thread, then it has to be marshalled to the UI thread. This might be the reason for a delay you are seeing.

DoDrawingLoop() performs the drawing synchronously on UI Thread.

Does that help answer the question? I think in any case, RenderPriority.Immediate isn’t a good idea. Id love to know more about what you are trying to do to see if we can help, and again, my apologies for the tardy response. I’ve raised this up with the team who do a good job at helping customers on our priority support tickets, but sometimes leave the forums unattended…

Best regards,
Andrew

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies