Double Buffer in Plot?

[steevcoco]

Has there been some NT client provision made to ease double buffering in Plot? I see that Invalidate always invalidates the entire rect for every incoming tick ...

(To spare thread replies: I know I could round through all kinds of events to check for what would invalidate my Indi, like changing the chart scale [itself which might not be easy] -- but can't stand that type of hunt-and-peck coding ...) I was hoping for the Invalidate handler to pass more useful information for me to determine what to redraw.)

On this topic: my indi IS doing all it's drawing in the Plot method: to do this in the OnBarUpdate handler would require me adding a TON of draw objects; and that's why I went for the Plot method to begin with. So I don't want to try to manage all the dozens and more draw objects that would be created in the OnBarUpdate method. ... And I bring that up because it's possible NT has some provisions for optimizing drawing through OnBarUpdate -- because it manages Plots in many other ways -- but it's possible that nothing would actually be gained that way, and ultimately what I'm hoping for IS to implement double buffering.

[NinjaTrader_Brett]

Hello,

Thanks for the post.

Wanted to make sure we are on the same page as there might be some confusion.

Double buffering has nothing to do with only Invalidating a specific section of the chart, double buffering is a method to reduce flicker on complex draw operations. NT7 does double buffering already on its charts and is enabled.

Invalidating only a specific region of the display to reduce the redraw time I believe if what you are referencing and even internally we invalidate the entire chart. So I would take this approach as we do not have any kind of smart invalidate here.

-Brett

[steevcoco]

Yes: I want to manage my own BufferedGraphics, and do all my drawing on that -- so I can e.g. draw ONLY NEW DATA when a tick comes in (which most of the time is confined to just the last bar) ...

I need to know if the chart scale has changed, and many other things; or if nothing has changed except a new tick in the last bar ...

This is to effect nothing more than reducing the amount of drawing my Plot method needs to do on each invocation.

... Perhaps it's actually as easy as checking bounds, min, max, and the X-pixel of the first and last bar to determine if all is the same ... ??? -- That is easy enough for me to try quickly ...

[NinjaTrader_Brett]

I see, so you want your own drawing on top of the chart so that you then could call invalidate() and redraw at a different interval then NT does in an attempt to improve performance.

Unfortunately this is unsupported and I don't have any tips or details I could give on doing this as I've never seen this attempted before.

My only advice would be the challenge you to make sure such effort really is necessary and that this is the true bottleneck you needed to solve, as I have not heard of people running into issues here. However if you profiled your code and identified that as a problem area and there is no optimization you could do on your Paint method then it for sure is worth investigating further.

-Brett

[steevcoco]

That's not quite it; but I do understand it's surely unsupported.

The optimization is simple, and clearly seen to be uncostly: the plot method is simply like this:

foreach (painted bar) {
several invocations of Draw to draw the data at each bar
}

With the double buffer, on those plot invocations that are raised simply because of the last incoming tick, it would become like this:

clear the rect on my buffer for the last bar
foreach (painted bar) {
if != the last painted bar, then continue
// Now ONLY repainting the last bar
several invocations of Draw to draw the data at each bar
}

I need no changes to refresh, and no invalidating. The buffer is a simple BufferedGraphics, I draw onto it for all my indi's data, the rest is transparent, and at the end of plot you blit the buffer into the given plot graphics. It's easy to see that the times where the only thing that's changed is the last incoming tick will be frequent, and I don't need to worry about many other factors: my plot method will pair down to drawing a single bar instead of every bar every time -- when the only thing that needs repainting IS the last bar ... And on those times where the whole chart needs a repaint, the cost of managing the buffer is negligible. It's a matter of being able to know when you can repaint only the last bar.

I am still giving it a try; and good or bad, I'll post my results! ...

THANKS as always! Cheers!

[steevcoco]

Well: in the first crude test, I'm going to proceed with some minor optimization and test again:

I did a crude test fast-forwarding through a half session at 500x and with buffering, I saw a 16% reduction in total time. Forcing the buffer to completely redraw every time gave a 20% increase in time.

I will quickly implement a crude scroll and expect to see a much higher yield.