Long term I think it would be interesting for plottables to be able to give their own tooltips (probably following the mouse around). However I wanted to see if you would consider this in scope for ScottPlot. I also didn't want to add mouse following in case it needs to be changed for #683.

In my mind, plots would be able to do something a little like this on mouseover:

Now, there are two tooltips because plotlyjs is like that, but it is what it is.

Hey @Benny121221, thanks for this! I don't think I would have thought to come up with an arrow tip shaped like that, but it looks really clean and I like it a lot!

The architecture raises a few interesting possible directions:

• Currently you have a special list of tooltips that gets rendered last, but we could further embrace the idea and have a list of "annotations" that are always displayed above the plot. This could include things like Annotation, Arrow, Tooltip, etc.

• Another option is to keep everything a Plottable in one plottable list and make the user arrange the order of things.

• Another option is to to add a flag to the IPlottable to indicate that it should be rendered on top. I keep putting this in than taking it out. A style I like here is to have an enum that says all the possible layers: figure background, data background, plottables, data frame, axes, annotations

• I originally intended Renderable for things that did not use coordinates, and Plottable for things that used the axis system. I guess technically this is one reason the tooltip is broken as-is, because it doesn't support multiple axes. This might justify making it a Plottable after all 🤔

I'll keep exploring these ideas and work on this PR some more tomorrow!

Thanks again
Scott

Thinking out loud... OHLCs might benefit from something like "highlight candle nearest cursor" (easy because only the X axis would have to be considered), and the highlight could be a colored tooltip with the corner symbol that looks just like the picture you showed. Probably low priority, but it might be pretty straightforward to implement.

Currently you have a special list of tooltips that gets rendered last, but we could further embrace the idea and have a list of "annotations" that are always displayed above the plot. This could include things like Annotation, Arrow, Tooltip, etc.

I like this idea, it makes it feel less like a one-off exception and more like a fleshed-out part of the API.

I originally intended Renderable for things that did not use coordinates, and Plottable for things that used the axis system. I guess technically this is one reason the tooltip is broken as-is, because it doesn't support multiple axes. This might justify making it a Plottable after all 🤔

That's a good point, although can "normal" plottables do this either? I thought secondary axes are just visual, a plottable drawing at point (x, y) will always draw at (x, y) on the primary axes?

Thinking out loud... OHLCs might benefit from something like "highlight candle nearest cursor" (easy because only the X axis would have to be considered), and the highlight could be a colored tooltip with the corner symbol that looks just like the picture you showed.

Yeah, I think OHLCs and Candlesticks are prime candidates for this because it's difficult to read precise values off of them (or maybe I'm just not paying enough attention in my ECON classes). Plus things like trading volume aren't shown by a candlestick or an OHLC plot, but is certainly useful information. Although I know that candlesticks are often used more for technical analysts to see patterns than to read off the 3rd decimal place.

And I think the axes themselves might benefit from tooltips? For example, you could have a short form date like 1/20/21 which expands to January 20, 2021 in the tooltip. Or scientific notation expanding to decimal form, log axes to conventional axes, or like I saw in a lecture today which converted what are decimals on the axis to exact value forms.

@Benny121221 Thanks for your input!

Multiple Axes

I thought secondary axes are just visual, a plottable drawing at point (x, y) will always draw at (x, y) on the primary axes?

Actually, IPlottable has two numbers that define which axes the data lives on.

Those numbers get read right before calling Render() and are used to build the dims object that gets passed in. dims is automatically adjusted so GetPixel() methods already know which axis they're working at. Therefore, anything that implements IPlottable automatically has support for multiple axes.

Financial Charting

my ECON classes

Haha I'm going to try not to get bated/triggered into writing a huge text block here. Suffice to say I'm passionate about economics, finance, personal finance, investing, and I'm morbidly fascinated by the intersection of meme culture and day trading and swing trading (and don't get met started on crypto!). I will say that learning how to manage investments (deciding savings rate, asset allocation, risk tolerance, tax strategies, etc.) is super intimidating at first, but amazingly empowering once you start to figure it out. At the same time virtually the entire "financial services" industry is out to get you, so it's quite a minefield for people getting started. After losing a fortune investing in a popular company of the day, Isaac Newton wrote "I can calculate the motions of the heavenly bodies, but not the madness of the people". I really enjoyed A Random Walk Down Wall Street and its punny title. I'll just leave it there I guess.

I'm torn on whether or not to improve financial charting. It's easy to add little things here and there, but the more we say ScottPlot supports financial charting the more we will attract a whole crowd who may ask for really important financial features that aren't really at the current core of what ScottPlot is made for. Check out some YouTube videos showing people using TC2000, probably the most popular trading software for retail investors. Most of those features could probably be implemented by ScottPlot, but may be best created as its own control specifically for financial charting. I've gotten a few pings about this, and there may be some commercial opportunity here. Since such software would obviously be used to make money (or at least attempt to), perhaps the financial control could be licensed as GLPL and companies would have to pay for a custom license. I'm not really interesting pursuing this at this time, but the idea may be worth exploring as the primary library stabilizes (if that ever happens).

Tooltips on axes

This is an interesting idea! I'd probably prioritize it pretty low compared to the other things on my plate, but it certainly seems possible.

This PR

I'll keep working on this over the next couple days and hopefully come up with a solution that feels natural.

Thanks again for all your input along the way!

...but may be best created as its own control specifically for financial charting...

I'm intrigued, I do think a dedicated financial charting control would be interesting, but I'm also intrigued just by the idea of a control for a specific field.

I vaguely thought about creating something which wraps ScottPlot to add a couple math-specific features. I never did because I couldn't think of enough reasons to do so (and most of them got merged into ScottPlot proper anyways). The features were:

• Vector Fields
• Function Plots
• TeX rendering on axes (briefly mentioned in Vector fields #439)
• Slope fields (probably better done by hooking up a CAS system to vector fields anyways)

#446 brought up allowing images as axis labels which would allow (La)TeX rendering to be handled by the user. I wonder if a simple package like ScottPlot.TeX could be created to do something like this:

plt.YAxis.Image = ScottPlot.TeXRender("\int \sec\theta \: d\theta")

Or, if you wanted to get flashy with extension methods:

plt.YAxis.Image.FromLaTeX("\int \sec\theta \: d\theta");

This package wouldn't necessitate adding another dependency to ScottPlot, although I confess that just adding one feature does sound pretty overkill for just one package.

In #412 adding images as axis labels is checked, but I don't know any way to do this? Is this an oversight? If not I think a demo would be fitting.

I'm torn on whether or not to improve financial charting. It's easy to add little things here and there, but the more we say ScottPlot supports financial charting the more we will attract a whole crowd who may ask for really important financial features that aren't really at the current core of what ScottPlot is made for.

Yeah I get that, I generally try to contribute to the library in areas where I feel I can help, but unfortunately I'm not much into trading (and certainly not technical analysis). My interest in economics is mostly in macroeconomics and public policy (I used to work in a provincial legislature).

I think a common rule in open source when it comes to feature requests that are relevant but not the main focus of a project is that they get given a pretty low priority unless the feature request is accompanied by a PR. After all, code review and testing generally doesn't take as long as developing it from scratch. I don't know if that's the line you want to take, it's just the most common view that I've seen before.

There's some excellent discussion here! I'll try to wrap-up this PR but we can continue to discuss here (or in Discussions?)

This PR

I made the tooltip a plottable after all, and its height in the plottable stack is determined by its order. I'm trying to not keep long-running PRs, so I'll go ahead and merge this in but you're welcome to offer suggestions/improvements.

Ideas for more tooltip features

• If you want to add tooltip support to OHLC charts you're welcome to (although it's low priority, so only if you're interested). Since multiple plottables will use tooltips, it may be time to create a static class for drawing tooltips that the plottables can call.
• I noticed rendering artifacts at the end of thick lines for closed paths. I hacked a workaround here by duplicating two points instead of just one, but there is likely a more elegant solution and a standalone class could explore this better
• You may consider using Graphics.TranslateTransform to center the Graphics at the X/Y point at the tip of the arrow before drawing the tooltip because then the math gets a lot easier. Those edges and corners are confusing!
• I called Graphics.DrawClosedCurve on the PointF[] just to see what would happen, and it was an interesting effect. With a little tweaking, it might be a way to make a softer tooltip, or one that resembles a thought bubble.

Financial control

I'm intrigued, I do think a dedicated financial charting control would be interesting, but I'm also intrigued just by the idea of a control for a specific field.

I think the reason it merits its own control is because of how the X axis is handled in financial charts. It's always DateTime, but they're unevenly spaced. That's a lot for the end-user to keep track of, but a control which wraps a Plot and has methods to set data and styling would make this way easier.

A control could wrap most or all of the ScottPlot complexity, and all the functions the user interacts with could be named correctly according to their financial terms. This becomes especially clear when you think about methods like AddSMA(10) or AddBollinger(10).

A financial control could also automatically handle all the mouse tracking so the user never has to think about that. In summary, the reason I think a control is good here is so it could just expose the features relevant to "chartists", and not require the adopter to learn the ins and outs of ScottPlot and the little hacks required to make financial charts look good.

Image Axes

adding images as axis labels is checked, but I don't know any way to do this? Is this an oversight? If not I think a demo would be fitting

Yeah, this is an oversight on my part. It may have been supported at some point, but when I re-wrote the Axis module I didn't add support for images. Reconsidering this now, I wonder if AddImage() could be most easily modified to do this using some type of configuration to (1) not clip to the data area and (2) center the image where the axis label would be. I agree though that a demo is fitting! I added this to #651 but I'll probably work on some higher priority tasks first.

Finance

unfortunately I'm not much into trading (and certainly not technical analysis). My interest in economics is mostly in macroeconomics and public policy (I used to work in a provincial legislature).

Not sure if you're familiar with Reddit's wallstreetbets (WSB), but if you ever want to see some craziness look them up. There are some YouTube videos where people highlight some of the craziest stuff that goes on there. I'm a pretty conservative hands-off bogleheads.org style investor, but I bet the majority of people who would use a financial charting tool we make would be more of the WSB crowd (and perhaps overlap with people deep into trading crypto), and I'm hesitant to attract that kind of drama here. I'll continue to think about it

Prioritizing Feature Requests with PRs

I think a common rule in open source when it comes to feature requests that are relevant but not the main focus of a project is that they get given a pretty low priority unless the feature request is accompanied by a PR. After all, code review and testing generally doesn't take as long as developing it from scratch. I don't know if that's the line you want to take, it's just the most common view that I've seen before.

I agree this is a common strategy for mature libraries. My goal for the last few months (and one I hope to wrap up here in the next couple weeks) is to get this new ScottPlot 4.1 API stable, then have really nice documentation, and make a few YouTube videos walking through how to do common things with ScottPlot. I'm going full speed ahead prioritizing whatever I think will make ScottPlot easier to document and figure out. Hopefully after that it'll settle down a little, and we can switch to the slower PR/review style of feature inclusion rather than the 4.0->4.1 hurricane that's been going on lately. That's my plan at least, we'll see how it goes!

... relevant to "chartists" ...

Wow, that took me back to AP history, those were the days.

Not sure if you're familiar with Reddit's wallstreetbets

Yeah, I have had the (mis)fortune of encountering it before. I think that if you're worried about attracting the WSB types then being a library is fortunate for ScottPlot. Most people aren't developers, so they'll use someone's app which may use ScottPlot and that app will attract most of the drama. However, I don't know how much second-hand drama there'd be from the app developer.