improved dash styles #5917
Description
Reviewing the changes in #5774, I realized that one of the original proposals from the BoF, of fixing up the dash styles to be less terrible, got lost somewhere along the way. IMO the current non-solid dash styles are pretty much unusable. Each on its own might be okay, but when you use them on the same plot (and isn't the whole point of these that you put them on the same plot to make it easier to tell lines apart?), then they have wildly varying visual weights and the dotted style in particular is almost invisible. (This is similar to the problem with the old color cycle, where some colors high much higher contrast than others; fixing that required switching to a set of isoluminant colors. Similarly, we should make the dash style closer to isoluminant.)
Here's a quick mock-up of a better set of dash styles. Left is #5774; right is #5774 + better dash styles:
(Code: https://gist.github.com/njsmith/ad4958cd1eb674fbed67)
The reason this is an issue rather than a pull request is that it looks like currently the dash styles are hard-coded constants in GraphicsContextBase and can't be touched by the RC system, and I'm not familiar enough with the life-cycle of GraphicsContext objects and their interaction with the RC system to fix this without some hints. Happy to make a PR if someone points me in the right direction :-)
Activity
tacaswell commented on Jan 26, 2016
👍 Sorry this got lost.
WeatherGod commented on Jan 26, 2016
Wow, I do like these a lot better than the current ones. I also remember a
discussion about making the strokes and spaces proportional to the line
width. Any thoughts on that?
On Tue, Jan 26, 2016 at 10:36 AM, Thomas A Caswell <notifications@github.com
mdboom commented on Jan 26, 2016
👍 from me as well. I'll probably throw an implementation of this (based on the numbers in @njsmith's gist) on the #5774 pile.
mdboom commented on Jan 26, 2016
As for implementation, @njsmith is right about things being too hard-coded at present. I see at least two ways forward:
njsmith commented on Jan 26, 2016
Making the stroke units be proportional to the line width is probably a good idea, but I guess more work and could be done as a separate step later?
I guess I should point out that I haven't done any research on how other systems handle dash styles. Even a quick attempt is a big improvement though :-)
On a side note. I know it's been a long road and a lot of effort, but I am really surprised how much better things look in #5774 compared to 1.5. Even
njsmith commented on Jan 26, 2016
... this trivial plot has what, at least for different substantial style improvements? 2.0 is going to rock :-) thanks for all the work you put in making it real!
mdboom commented on Jan 26, 2016
Thanks for the reminder about dash styles being proportional to width. That's something I've been meaning to fix for a long time. I think we can tie that behavior to our special backward compatibility flag (_internal.classic). I think we should definitely do that while we're at it.
efiring commented on Jan 26, 2016
Regarding using width as the unit for dash length: you might need to have some minimum value. I suspect that strict scaling would not work well for very thin lines.
mdboom commented on Jan 27, 2016
That's a good point. Some sort of function from linewidth to dash length will likely need to be applied.
Fix matplotlib#5917. New dash patterns. Scale dashes by lw
Fix matplotlib#5917. New dash patterns. Scale dashes by lw
Merge pull request #5926 from mdboom/new-dash-styles
Merge pull request #5926 from mdboom/new-dash-styles