Many text drawings causing problems

[KhaosTrader]

Currently I instantiate 1 object that holds all the fonts and color brushes which is passed to 3 different objects that create draw objects. Should I instead have each of those objects instantiate their own object that holds the font and color brushes?

[NinjaTrader_ChelseaB]

Hello KhaosTrader,

An object is an object. I put mine in an array of brushes. I don't see how this would be any different in a list, dictionary, keyvaluepair, or custom class.

As long as the object is only created once and isn't created in a method that is triggered repeatedly, then it should only have one location in memory.

However, the indicator I have created is meant to clearly show that Draw.Text() itself should not be responsible for the error when used a reasonable amount of times on a chart.
(Within reason means, all objects will take memory and will have a limit to how many can be created)

I suggest you go one of two ways.
Either create a copy of this script and start reducing your code to the barebones minimum to reproduce the error.
Or start from my example and build on this.

[KhaosTrader]

I think I figured it out....

I Called "RemoveDrawObjects();" from the OnStateChange() event in both the State = State.Terminated and also in State=State.Configure.

So after I removed both of those lines, no more crashing

However, I am getting an error still, and its this:
"Chart rendering failed. There is likely a problem with a chart object's OnRender method. D2D error = 'Upgradeable lock may not be acquired with read lock held.'"

I am going to do a bit more testing, and if the error persists, I will create a new thread on this error.

[KhaosTrader]

Ok, so Errors are gone.. but it takes a long time for Ninja to shut down, the UI shuts down, but on Task manager the process runs for 30+ seconds if I had 5 or 6 charts open each having 80k or so drawing objects.

I deleted a few things in my code, that I believe caused the problems. Firstly, took out "RemoveDrawObjects()" calls, Secondly, I used to set all my custom instantiated objects to null on both 1) Staturs.Termination and 2) Status.Configure.

So now the problem is that NinjaTrader persists in the background after I shut the program down for a number of seconds, 30 to maybe 40 seconds or longer, depending I believe on how many charts I had open and how many drawings were on each chart. The problem is that I can't relaunch Ninjatrader until that languishing process is cleared out of the task manager. of course, I can end it manually with the task manager.

Is there a way to force the shutdown for expeditiously on Ninjatrader termination?

[NinjaTrader_ChelseaB]

KhaosTrader,

When removing an indicator, all of the drawing objects made by that indicator will automatically be removed. Do you add this line because the objects were not being removed?

If you test the script that I have provided you with all other workspaces closed and only a few charts with only this test script in the workspace, are you able to reproduce this behavior?

Have you reduced a copy script to only the minimum necessary code to reproduce the behavior? (Looking for a script with only a few lines of code that demonstrate the behavior similar to the test script I have created for you)

No, there is not a way to force NinjaTrader to close. I would not recommend this.
If there is code still executing this can cause a delay. I would recommend debugging any script that can reproduce the behavior.

[KhaosTrader]

Hi,

The charts and everything closes, that is not the problem, the problem is that once the charts and application close visually, it seems that Ninjatader is processing some stuff for a while. As when I look at the task manager its still there.. If I wait 30 or 40 seconds (if i have huge charts) it closes. If I have smaller charts or charts with no draw objects, it closes in 3 or 4 seconds or less...

I ran your test script and it seemed to close quickly. Maybe the objects I instantiate take a while to close down -- i am not sure how i can go about finding or tracing the sequence of object destruction in my code... any suggestions would be welcomed.

[NinjaTrader_ChelseaB]

Hello KhaosTrader,

Thank you for confirming the script I have provided as an example is not able to reproduce this behavior.

This would suggest that calling Draw.Text() is not responsible for the delay when shutting down and there may be other code causing the behavior.

Have you reduced the code in the script to only the code necessary to reproduce the behavior?

I would suggest that if you have any timers that these be disposed, if you have custom threads or tasks running end these, if you have any other items that need to be disposed, dispose of these.
Without knowing what code is in your script, I can only offer suggestions of possible items that could cause a delay when shutting down.

[mgin98]

Similar draw.text issue

I am having a related problem using draw.text (using latest NT8 build). I do not get errors but after running this simple script on a 5-minute chart in replay mode, the chart comes to a standstill at around 70 bars or so.

This is an exaggeration of what I'm doing in my indicator but it reproduces the problem in a shorter time. Memory is not being affected but toward the 70-bar mark, my CPU starts heading toward 50% utilization and stays pegged there (quad-core i7 2.6ghz) with replay advancing 1 replayed sec for every 30 realtime seconds that has passed at 100x.

I've reproduced this on two different computers so far.

[NinjaTrader_ChelseaB]

Hello mgin98,

Likely there are too many objects being drawn and this is maxing out the core that the indicator thread is running on.

Each computer will have a different amount of objects that it can draw and will have a different speed depending on the resources of that computer.

No computer would be able to draw an infinite amount of drawing objects without eventually running out of resources and becoming sluggish until fully maxed out.

How many cores does your CPU have?
If this has two cores and is becoming slow at 50%, this would indicate the CPU is overloaded and you should reduce the number of objects being drawn.

[mgin98]

Hi Chelsea, thanks for the quick response...if the CPU is having to redraw the historical objects along with new objects upon each new incoming bar, I must be hitting a ceiling. I have a quad-core and see all 4 cores hit the 50% mark consistently at around the same time if using the same replay timeframe when testing. I will have to take a different approach to what I'm doing it seems. Thx again.