Problem with Draw.Ellipse(...)

[strategesis]

It's not possible to reliably approximate a circle using Draw.Ellipse() (outside of the OnRender() method,) because there's no way I can find to determine dy / dx. In other words, given a known horizontal pixel extent as computed by ChartControl.GetXByBarIndex(endBarsAgo) - ChartControl.GetXByBarIndex(startBarsAgo), how can the correct values be computed for startY and endY so that the ellipse which is drawn will be symmetrically circular?

In NT7 it was possible to compute delta price for a given delta pixels (and vice versa,) but other than by using the ChartScale parameter in the OnRender() method, there doesn't seem to be any way to do that in NT8.

Can the Draw.X() method be used in OnRender()? If so, what are the constraints?

Could you tell me how to convert delta pixels to delta price in NT8 outside of the OnRender() method?

Or, could a Draw.Circle(...) method be added?

Thanks!

[NinjaTrader_Jesse]

Hello,

Thank you for the question.

I would first like to address what you are trying to do as I am not clear on why you need to use OnRender items outside of OnRender and Draw items in OnRender.

OnRender items would generally not be mixed into OnBarUpdate, This would be the same in NT7 with the Plot Override. Instead you would assign values to variables from OnBarUpdate and then display those variables using OnRender when needed.

The Draw. methods can be called from OnRender although would not be recommended as OnRender is called very frequently and there is not a need to call these methods in excess.

Using OnRender you could use RenderTarget.DrawEllipse() instead and supply it with variables or values that are updated in OnBarUpdate.

Can you explain what problems you are running into further as I am unsure the reason for Mixing the two separate drawing methods, it sounds like OnRender should be what you need to both Draw and do price to pixel conversions.

I look forward to being of further assistance.

[strategesis]

I have an indicator which detects and draws swing points. One thing that differentiates it from others is that it ranks them hierarchically by degree of significance, in a way analogous to an Elliot Wave "degree of trend" ranking of up and down swings.

So it's important to be able to visually show the indicator's classification of each swing point's degree of significance. It does that by drawing circles (ellipses) of different sizes. Which it does perfectly on NT7, but can't do on NT8 for the reasons I explained in my initial comment.

Yes, I could re-implement it to use OnRender() -- and draw directly to the RenderTarget -- but that would defeat the reasons I didn't implement it originally in NT7 to draw directly to a Graphics object in the Plot() method:

1) I wanted to leverage the graphics framework provided by NT, instead of having to develop my own higher-level graphics abstractions tailored to the domain of price charts. Didn't NinjaTrader develop its own higher-level graphics framework on top of Windows Forms so that its customers wouldn't have to do that themselves?

2) I wanted to avoid creating yet another dependency on a code library (Windows Forms) where I have no control over when and how it changes. Note that I would have had to completely re-implement not just the indicator, but also my (hypothetical) domain-specific graphics library (based on Windows Forms) in order to port the indicator to NT8, had I chosen to do in NT7 what you suggest I should do in NT8. I've been coding for almost 40 years, so I have enough accumulated experience to know with great certainty that the same thing can and will happen again.

3) OnRender() is never called when State == State.Historical. My current code depends on the fact that the NT DrawObjects a) persist once defined, and b) can be created incrementally during the processing of historical chart bars. Therefore, using OnRender() would be a major reworking of the code for this reason alone, without even considering the API differences between NT's Draw.X framework and Microsoft's RenderTarget API.

I'd strongly prefer to avoid having to have to use one algorithm to draw swing points historically, and another to do so when processing real time data.

4) The only reason I need to do price/pixel conversions is to keep the height of what's drawn proportional to the width. Your Draw.X methods provide no way to do that at all in NT8, even though it was possible to use them to do that in NT7 using undocumented method calls.What I need -- and I strongly suspect what most of your customers need -- is the ability to draw objects where either the pixel height should be some multiple of the pixel width or where the pixel width should be some multiple of the pixel height (typically, but not necessarily, a one-to-one ratio.)

Although one typically needs to use both time and price to define where to anchor what is drawn, one only rarely needs to define both the height and the width of what is drawn using both very specific left and right bar indexes and very specific min and max price points.

A swing point, for example, occurs at a specific point in time and at a specific price. Mathematically and conceptually, it's a dimensionless point. So when it's drawn, any extension either horizontally or vertically is not driven by the market data, it's driven by the need to make it usefully visible to the user.

That's probably why your graphics framework offers Draw.Dot in addition to Draw.Ellipse: Without Draw.Dot, there'd be no way to draw a circular object except accidentally, in cases where the pixel width of an ellipse just happened to be essentially the same as the pixel height. I strongly suspect that Draw.Dot exists to solve that problem.

The problem with Draw.Dot is that there's no way to specify the size of the dot, if you wanted to use it instead of Draw.Ellipse. Many of the other Draw.X shapes have the same problem, unless they're like Draw.Ellipse, which has a different issue (the one I've described in my initial comment.)

Isn't the whole point of the NT Draw.X graphics framework to make NT far easier to write useful code for? To make it unnecessary for users to develop their own graphics framework tailored to the domain of price charts? Wouldn't enhancing the Draw.X methods so that they could be used to draw shapes anchored by bars and prices, but whose proportion of height to width (or proportion of width to height) can be kept invariant, significantly increase the utility of the Draw.X framework, and significantly reduce the need for customers to roll their own graphics framework? Wouldn't that significantly reduce the impact on customers of having to port NT to yet another new MS graphics paradigm?

[koganam]

I have an indicator which detects and draws swing points. One thing that differentiates it from others is that it ranks them hierarchically by degree of significance, in a way analogous to an Elliot Wave "degree of trend" ranking of up and down swings.

So it's important to be able to visually show the indicator's classification of each swing point's degree of significance. It does that by drawing circles (ellipses) of different sizes. Which it does perfectly on NT7, but can't do on NT8 for the reasons I explained in my initial comment.

Yes, I could re-implement it to use OnRender() -- and draw directly to the RenderTarget -- but that would defeat the reasons I didn't implement it originally in NT7 to draw directly to a Graphics object in the Plot() method:

1) I wanted to leverage the graphics framework provided by NT, instead of having to develop my own higher-level graphics abstractions tailored to the domain of price charts. Didn't NinjaTrader develop its own higher-level graphics framework on top of Windows Forms so that its customers wouldn't have to do that themselves?

2) I wanted to avoid creating yet another dependency on a code library (Windows Forms) where I have no control over when and how it changes. Note that I would have had to completely re-implement not just the indicator, but also my (hypothetical) domain-specific graphics library (based on Windows Forms) in order to port the indicator to NT8, had I chosen to do in NT7 what you suggest I should do in NT8. I've been coding for almost 40 years, so I have enough accumulated experience to know with great certainty that the same thing can and will happen again.

3) OnRender() is never called when State == State.Historical. My current code depends on the fact that the NT DrawObjects a) persist once defined, and b) can be created incrementally during the processing of historical chart bars. Therefore, using OnRender() would be a major reworking of the code for this reason alone, without even considering the API differences between NT's Draw.X framework and Microsoft's RenderTarget API.

I'd strongly prefer to avoid having to have to use one algorithm to draw swing points historically, and another to do so when processing real time data.

4) The only reason I need to do price/pixel conversions is to keep the height of what's drawn proportional to the width. Your Draw.X methods provide no way to do that at all in NT8, even though it was possible to use them to do that in NT7 using undocumented method calls.What I need -- and I strongly suspect what most of your customers need -- is the ability to draw objects where either the pixel height should be some multiple of the pixel width or where the pixel width should be some multiple of the pixel height (typically, but not necessarily, a one-to-one ratio.)

Although one typically needs to use both time and price to define where to anchor what is drawn, one only rarely needs to define both the height and the width of what is drawn using both very specific left and right bar indexes and very specific min and max price points.

A swing point, for example, occurs at a specific point in time and at a specific price. Mathematically and conceptually, it's a dimensionless point. So when it's drawn, any extension either horizontally or vertically is not driven by the market data, it's driven by the need to make it usefully visible to the user.

That's probably why your graphics framework offers Draw.Dot in addition to Draw.Ellipse: Without Draw.Dot, there'd be no way to draw a circular object except accidentally, in cases where the pixel width of an ellipse just happened to be essentially the same as the pixel height. I strongly suspect that Draw.Dot exists to solve that problem.

The problem with Draw.Dot is that there's no way to specify the size of the dot, if you wanted to use it instead of Draw.Ellipse. Many of the other Draw.X shapes have the same problem, unless they're like Draw.Ellipse, which has a different issue (the one I've described in my initial comment.)

Isn't the whole point of the NT Draw.X graphics framework to make NT far easier to write useful code for? To make it unnecessary for users to develop their own graphics framework tailored to the domain of price charts? Wouldn't enhancing the Draw.X methods so that they could be used to draw shapes anchored by bars and prices, but whose proportion of height to width (or proportion of width to height) can be kept invariant, significantly increase the utility of the Draw.X framework, and significantly reduce the need for customers to roll their own graphics framework? Wouldn't that significantly reduce the impact on customers of having to port NT to yet another new MS graphics paradigm?

Draw your shapes as text objects using Draw.Text(). That way, you have complete control over size and placement of the object relative to price points.

[strategesis]

How do you draw a circle using Draw.Text?

And what should be the height, using units of price, for a circle (or a rectangle) of width 3 bars, of the shape (whether circle or rectangle) so that the shape's height will have the same proportion to its width on any and all charts, regardless of bar type and/or of bar size?

[NinjaTrader_Matthew]

Isn't the whole point of the NT Draw.X graphics framework to make NT far easier to write useful code for? To make it unnecessary for users to develop their own graphics framework tailored to the domain of price charts? ?

I'm not sure I agree with this comment. The new draw framework was created so users could develop their own drawing tools which could be drawn manually and programmatically accessible from other NinjaScript types. There are helper methods in ChartControl and ChartScale which were developed to make it easier for users to write code for rendering, but that is not related to the UI Draw.X objects which are implemented. It's relevant for customizing your own rendered objects.

I think you may be looking at the problem from the wrong tool. Indicator rendering does not get called historically, etc, as you have pointed out. What you're looking for is a drawing tool object which you can now develop and look at existing source code to see how we achieved current implementation and modify behavior as such.

Regarding the RenderTarget.DrawEllipse() suggestion - this certainly would not work well from an indicator for what you're trying to do for reasons you have pointed out. You can write your own Drawing Tool now, and use it's OnRender to use RenderTarget.Ellipse to behave however you want. This is how you can leverage the graphics framework provided by NinjaTrader 8. Since the drawing tools are now completely open source so you can see exactly how they're done. This allows you to create an object that is set historically, and access/modify values later on, or even draw your custom tool manually.

If you're asking we provide a Draw.PerfectCircle(), or add some more helpers to chart,we can certainly add that to our list, but it would be some time before we got around to implementing enhancements at this stage. You may be able to achieve your goal just by making a copy of the existing Ellipse tool and adding overloads to a custom signature to do what you want.

[koganam]

How do you draw a circle using Draw.Text?

And what should be the height, using units of price, for a circle (or a rectangle) of width 3 bars, of the shape (whether circle or rectangle) so that the shape's height will have the same proportion to its width on any and all charts, regardless of bar type and/or of bar size?

Actually, I thought that you simply wanted to have different fixed sizes that you control. If you want to tie the sizes to bar sizes, there will have to be bar-arithmetic to determine size and then pass that size to the Draw.Text() method.