Did something happen to the chart rendering calculation between 8.0.26.1 and 8.1.1.7

[NinjaTrader_Emily]

Hello Emily,
until previous versions everything worked perfectly; since NT did the last update things have started not worked properly just exactly like WHICKED wrote. By the way, the developer didn't changed or modified anything so the problem is from NT side.

Best regards

Alex

Hello Alex,

Thank you for your reply.

If you are able to reproduce this on a script that comes with NinjaTrader by default, I would be glad to research the steps to reproduce the behavior and identify the cause. Since this is happening with a 3rd party script, you will have to reach out to the developer and they may need to debug their script to identify which part of the code is causing the unexpected behavior. I understand that this may have been working prior to the last update, though there is likely something happening programmatically within the script that could be causing this behavior. This needs to be addressed through the developer directly.

Thank you for your patience.

[llanqui]

I develop just for myself, and have the same problem on a NQ 2 Range or Renko chart, loaded just one day back.

(does not happen on ES/CL/UB/HG 2 Range or Renko, just NQ)

I have several indicators that draw various objects on the chart, arrows, dots, horizontal lines, vertical lines....some persistent and others only one at a time (i.e. same label)

I don't do any custom Rendering, just use Ninja Standard Draw methods

The problem seems worse when I have an active position. The chart can jump around and is not stable.

This only happens on the 2 Range or Renko charts. If I have a 10+ Range, with many more drawn objects, it does not do this. (but I don't trade on that chart). It doesn't do it on any other chart except the 2 Range/Renko NQ. Only the NQ.

I've stopped using Ninja's ATM as it is not good for scalping NQ in fast markets.

Wrote my own using virtual stops/break even/trail.

This is new so at least that should help a little.

It seems the problem may be related to the speed of the price action, perhaps something underlying having to do with messy sub bar price movements that Ninja has a hard time keeping up with.

and then perhaps the number of drawn objects

It seems to me that NT8 with WPF is much less stable on the graphics than NT7, and slower (in the graphics). Probably heavier on the graphics processor.

It could also be related to the type of draw object. And perhaps how far off the current chart panel it is.

If Ninja would look at these parameters, then probably they can find it.

[QuantKey_Bruce]

It seems to me that NT8 with WPF is much less stable on the graphics than NT7, and slower (in the graphics). Probably heavier on the graphics processor.

Regarding this statement specifically, NT7 relied solely on the CPU and rendered in software while NT8 offloads rendering tasks to the GPU via DirectX. Ergo, if you have a slow or no graphics card such as an inbuilt Intel graphics chip in a laptop, NT8 doesn't have anything to offload the tasks to and most of it falls back on the CPU, while if you have a great graphics card with high speed 2D performance, almost all of it gets offloaded to the GPU. So, you'll see much more difference in performance between NT7 and NT8 (with NT8 being tremendously faster) if you have a good graphics card.

[llanqui]

ok, thanks, yes good suggestion....before I was on a gaming laptop and didn't have this problem....now I have a Dell business desktop...it has a gpu but probably not a very good one

[Leeroy_Jenkins]

8.0.28 can confirm blinking.

[llanqui]

When I monitor the GPU with Task Manager, it never gets anywhere near a max out...so maybe it is not a GPU overload (in my case with a business class computer)

still happens occasionally on a 2 range NQ chart

seems to happen primarily during trades (orders, executions)

with the Ninja ATM it is worse

[Leeroy_Jenkins]

I also use one NQ range chart, and for me, it occurs right at RTH open. I don't have a very powerful PC (Intel graphics), so I don't think this issue is related to the GPU. Before 8.0.28 I have been using 8.0.26.1 since its release and haven't experienced any problems whatsoever.

[Leeroy_Jenkins]

Pretty rare bug. I see it maybe once a month.

[llanqui]

it is possible it is related to the number of draw objects on the chart, the type and where they are on the time/price ... possibly off visible chart panel draw objects still consume resources?

[WHICKED]

funny how we have PROVEN that it is causing issues - yet NT's blanket statement is - its a third party problem.....

NOOOOOOO - we have said multiple times that multiple vendors and other programmers have seen the SAME THING when they went to the newer versions of NT.

if you need a refresher 8.0.27.0 DID NOT have this issue 8.0.28.0 started the issues and it HAS NOT BEEN RESOLVED since.

Pretty apparent that the developers dont want to go and look at the differences between those two versions specifically on chart scaling or chart refresh to figure out what change is causing the issues.

Sorry, been quite a while since an update and it still is happening in 8.1.3.0 - so cant use 8.0.27.0 since it no longer works with brokers.

[llanqui]

I am sing version 8.0.28.0

I had a long thread on this issue, and it was answered to my satisfaction

https://forum.ninjatrader.com/forum/ninjatrader-8/indicator-development/1304483-render-engine-drill-down

it seems Ninja is not using the GPU to render, and since all the graphics are done in one CPU Core ..that one Core (could be virtual) can max out even if the overall system is well within tolerance.....then the rendering could be out of synch with the data feed.

this was the case with my code...I had way too many draw objects, and too many workspaces open, for Ninja to handle. The overall CPU usage was rarely above 50% but the rendering would lag the price in fast markets, for example NQ during Open or News

I reduced the number of draw objects, and the number of open workspaces and now the chart is stable, keeps up with the Market Data, does not jump around or act badly

[WHICKED]

I am sing version 8.0.28.0

I had a long thread on this issue, and it was answered to my satisfaction

https://forum.ninjatrader.com/forum/ninjatrader-8/indicator-development/1304483-render-engine-drill-down

it seems Ninja is not using the GPU to render, and since all the graphics are done in one CPU Core ..that one Core (could be virtual) can max out even if the overall system is well within tolerance.....then the rendering could be out of synch with the data feed.

this was the case with my code...I had way too many draw objects, and too many workspaces open, for Ninja to handle. The overall CPU usage was rarely above 50% but the rendering would lag the price in fast markets, for example NQ during Open or News

I reduced the number of draw objects, and the number of open workspaces and now the chart is stable, keeps up with the Market Data, does not jump around or act badly

sorry, but that is not a reasonable answer by NinjaTrader. Their previous versions did not have the issue. So whatever they changed broke their rendering system.

if they are literally saying that you must reduce number of draw objects then they need to release a statement about how many draw objects it now support.

it’s disheartening to hear that NT won’t do a code comparison to fix the issues.

[NinjaTrader_ChelseaB]

Hello WHICKED,

If there is a bug that we can identify, we do want to report this.

To identify the specific cause of an issue to report this to our development we must have a reduced test script, with only the bare minimum code to reproduce the behavior.
This will be true of any thing you find that you feel is unexpected or incorrect behavior.

If this is a script you have created, reduce the script to the bare minimum necessary to reproduce. Hopefully this will only be one or two lines of logic.
Export the script and attach this to your next post.
By default we will add the script to a 1 minute ES future chart. If there are special steps to reproduce, please include these.
If I am able to reproduce the behavior I will report the behavior to our development and provide the reduced test script and steps to reproduce.

"if they are literally saying that you must reduce number of draw objects"

This has been the stance of development since day one of NinjaTrader 8.

From the help guide:
"When using Draw methods, a new instance of the Draw object is created including its custom rendering and calculation logic. These methods are convenient in many situations, but can quickly introduce performance issues if used too liberally. In some situations, you may see better performance for rendering via SharpDX in OnRender()."
Help guide: NinjaScript > NinjaScript Best Practices > Performance practices > Using DrawObjects vs custom graphics in OnRender()

This means if there are more than just a few Draw method calls in the script, stop using Draw methods and custom render all shapes in OnRender(). It's also advised only running logic for the visible bars (ChartBars.FromIndex to ChartBars.ToIndex).

[llanqui]

Well, it makes sense to me that if all the Renders are done in only one virtual core, that it could be easily overwhelmed in fast markets with lots of draw objects...it seems that workspaces that are not "in front" need the rendering also...so lots of draw objects on multiple workspaces...well...

if one is looking at tick charts, or 2 range /renko ...these create hundreds of bars in 10 seconds in a fast market like NQ at News or Open (sometimes)

I found that when I closed unnecessary workspaces and stopped trying to put (a lot of) analytical draw objects on the historical part of the chart, and reducing the look back, my problems with the unstable chart went away even in a very fast NQ market

but I'm using 8.0.28.0

I have a Core I7 3.6 / 4.0 ghz

[llanqui]

well, if you can capture the flickers on a video it may validate this to the support staff

maybe also an XML copy of all the workspaces that are open, so they can see the load

as well, as drawing in the future...it makes sense that AutoScale is off , especially on a non-time based chart, such as Range / Renko. In that case there is no exact coordinate point that can be drawn

before I reduced the number of draw objects I had flickering, jumping on the chart, as well as lagging rendering, sometimes far behind the market data

as well the NinjaScript Utilization Monitor (found Right Click inside of Ninjascript Output) helped me see the indicators that were using the most resources

that does not show if a virtual core is maxed out, or a momentary spike (could cause the flickering?)....just a general ongoing utilization

??