Freezing Brush

[blar58]

I am a bit lost when comes the time to freeze Brush.

Let's say am doing this :

SharpDX.Direct2D1.Brush thisBrush = new SolidColorBrush(Color.Black).ToDxBrush(RenderTarget);

thisBrush.Dispose();

Do I have to do something else ?

[NinjaTrader_PatrickH]

Hello blar58,

Thank you for your post.

The following is an example of changing a plot's brush by freezing it:

				Brush myBrush = Plots[0].Brush.Clone();
				myBrush.Opacity = 0.5f;
				myBrush.Freeze();
				Plots[0].Brush = myBrush;

Is this what you were looking for? If not, what are you attempting to do with the brush?

[NinjaTrader_Matthew]

I am a bit lost when comes the time to freeze Brush.

Let's say am doing this :

SharpDX.Direct2D1.Brush thisBrush = new SolidColorBrush(Color.Black).ToDxBrush(RenderTarget);

thisBrush.Dispose();

Do I have to do something else ?

It depends on where the brush was created, and where you are trying to access /modify it.

If the code snippet you posted was totally done in OnRender(), then there is no reason to freeze it.

It is not unless you try passing some object around to various events, that you would need to .Freeze(). This is because if the brush is not frozen, it can only be accessed/modified by the thread which created it.

For example, creating some global class variable in OnStateChange State.Configure (which runs on the UI thread), and then trying to modify it later in OnBarUpdate()-> you'd need to freeze the brush on OnStateChange(), since you are trying to access it later in an Instrument thread.

I do acknowledge the challenge as it can be a bit 'random' in that sometimes the UI and Instrument thread can be shared, so you can run some tests and have it not fail, but not until later down the road that you hit a situation where the thread context changes, and only then would you hit the access error. Due to this unpredictability, it is recommended to simply freeze a brush if you do not want to risk issues.

But with that said - I am personally comfortable not freezing a brush that I am willing creating and destroying in the same event pass, such as a single OnRender().

[blar58]

Matthew.
Thank you very much. That helps me better understand the Freeze() method.

Now that opens up more questions about the OnStateChange() UI Thread.

On the State == State.Historical I am creating a lot of new objects like SessionIterator, custom objects, variables, calling methods from objects etc ...

According to your answer I am creating these objects from the UI Thread but I am using these objects from the Instrument Thread !

Is that logical ?

[NinjaTrader_Matthew]

Matthew.
Thank you very much. That helps me better understand the Freeze() method.

Now that opens up more questions about the OnStateChange() UI Thread.

On the State == State.Historical I am creating a lot of new objects like SessionIterator, custom objects, variables, calling methods from objects etc ...

According to your answer I am creating these objects from the UI Thread but I am using these objects from the Instrument Thread !

Is that logical ?

My answer was specific to WPF Brushes which can only be modified from the thread which created them unless they are frozen. This is a design of the WPF implementation. The other objects thread safety may vary depending on their implementation.

OnStateChange is not entirely on the UI thread, it depends on the state.

SetDefaults/Configure run on the UI thread.

DataLoaded -> Realtime work on the Instrument thread.