I did notice this line: https://github.com/Benny121221/ScottPlot/blob/9cc49afe59a3964a2670536a97cdd45c573bfe18/src/ScottPlot/Renderable/Legend.cs#L145L146

For plots where this displays a line this makes sense. However bar charts in the legend are represented by a rectangle, which means for solid-coloured charts it is drawing a wide line instead of a rectangle. I don't think it's likely to cause any issues, however when I was looking to extend it to support non-solid brushes I ignored it as I assumed it would be elsewhere, because I expected rectangles to be drawn by FillRectangle. Maybe one could add MarkerShape.box to the enum and pass in a lineWidth of 0 for bar charts. I didn't make any changes because I wanted your opinion first. And now that I've extended it for patterned brushes it's more obvious that it draws the box for bar charts because there is a FillRectangle() method call.

Hi @Benny121221,
Confused only by the additional dependencies on the GDI. It would be useful if the brushPattern property was some kind of ScottPlot type. It might be worth choosing some of the best hatch patterns and creating an custom enum. All API calls use this enum. This does not apply to the current moment, but in the future it would simplify the task of implementing non-GDI renderers. Do not take this as a guide to action, just a wish.

Hey @Benny121221, this is awesome! I look forward to reviewing this PR in detail soon.

In the mean time, I do agree with @StendProg about minimizing reliance on direct System.Drawing calls where possible. I'm trying to eventually remove the System.Drawing dependency out of ScottPlot and allow ScottPlot to display graphics using different rendering systems (e.g., SkiaSharp + OpenGL, #521), so anything we can do now to abstract those calls away will help this transition later.

ScottPlot.Drawing.GDI.Pen() already exists and can be use to make this pen 👍

... extending the previous comment, I'd love to use a custom enum instead of System.Drawing.Drawing2D.HatchStyle

https://github.com/swharden/ScottPlot/blob/9cc49afe59a3964a2670536a97cdd45c573bfe18/src/ScottPlot/plottables/PlottableBar.cs#L42

Such an enum could have a None option so we don't have to use nullables to indicate we dont want hatching.

In reviewing System.Drawing.Drawing2D.HatchStyle docs I can see there are many, many hatch styles! Perhaps we can just support a few of the ones that make most sense for plotting, and implement them now using System.Drawing calls and later re-implement them using other drawing technologies when the time comes.

A good place for those hatch styles to live is next to the line styles enum in Style.cs:

https://github.com/swharden/ScottPlot/blob/4d06b49aa8ce85139fbc22a3a4990e311700ff6e/src/ScottPlot/Style.cs#L53-L61

You can make this change if you want, or I'll do it some time between now and merge.

Thanks again for this PR! The screenshot looks awesome, and again I look forward to reviewing it in more detail soon.

It now uses an enum which looks like this:

    public enum HatchStyle
    {
        None,
        StripedUpwardDiagonal,
        StripedDownwardDiagonal,
        StripedWideUpwardDiagonal,
        StripedWideDownwardDiagonal,
        LargeCheckerBoard,
        SmallCheckerBoard,
        LargeGrid,
        SmallGrid,
        DottedDiamond
    }

There is a corresponding ScottPlot.Drawing.GDI.ConvertToSDHatchStyle to facilitate converting between the two enums. Note that HatchStyle.None corresponds to null.

This PR solves issue #552

Matplotlib

I thought I'd mention I was curious how matplotlib names their hatch styles so I looked it up and it seems they use strings to define hatch styles.

Some of their styles get pretty advanced too:
https://matplotlib.org/2.0.2/examples/pylab_examples/hatch_demo.html

Interestingly their diagonal hatches are /, //, ///, etc.

GDI

For reference here's what GDI calls things: