Skip to content

FIX: Restore hatch color tracking edge color #7976

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 6, 2017

Conversation

tacaswell
Copy link
Member

Addresses #7901

Still needs docs and a closer look at the test images that get updated.

@tacaswell tacaswell added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Jan 28, 2017
@tacaswell tacaswell added this to the 2.0.1 (next bug fix release) milestone Jan 28, 2017
@tacaswell
Copy link
Member Author

Something is wrong with the hatch color of either collection or patches in svg (but not png).

Gets the color to use for hatching.
"""
if hatch_color is None:
raise ValueError()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a message to the error, so that the user understands what's going on?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, don't you want to check that the hatch_color provided is a color? That should fix the value error message.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is currently a debugging latch, will probably remove it before final review.

gc.set_hatch_color(self._hatch_color)
except AttributeError:
# if we end up with a GC that does not have this method
import warnings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to move this import at the top of the file?

except AttributeError:
# if we end up with a GC that does not have this method
import warnings
warnings.warn("Your backend does not have support for "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Your backend doesn't support setting the hatch color" is clearer for me (might be because I am a non native english speaker).

@tacaswell tacaswell force-pushed the fix_hatch_color branch 2 times, most recently from bdb3679 to 7196cd5 Compare January 29, 2017 05:11
@tacaswell tacaswell changed the title FIX: Restore hatch color tracking edge color [MRG] FIX: Restore hatch color tracking edge color Jan 29, 2017
@tacaswell
Copy link
Member Author

attn @jkseppan as I touched the innards of the pdf backend and attn @QuLogic as you were the last person to touch hatching.

@tacaswell
Copy link
Member Author

An eye-ball check confirms that the eps backend is working correctly as well :)

@tacaswell
Copy link
Member Author

ok, I think I am happy with where this landed (and it ended up being a lot less work (once I understood a few bits of code) than I had anticipated).

  • if an explicit edge color is set, use that for the hatch
  • if the default edge color (None -> 'none') then use rcParam['hatch.color']
  • bind rcparam at artist creation time (not at draw time)

Still needs some documentation work which I will do tomorrow.

@@ -1111,6 +1113,12 @@ def get_hatch_color(self):
"""
return self._hatch_color

def set_hatch_color(self, hatch_color):
"""
Gets the color to use for hatching.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: Sets

gc.set_hatch_color(self._hatch_color)
except AttributeError:
# if we end up with a GC that does not have this method
warnings.warn("Your backend does not support setting the "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you define set_hatch_color in the base graphicscontext class as a noop that prints the warning? (would avoid the repetition below).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is defined as a functional function it the base class, this is in case there are backends in the wild that do not derive from our base class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we suggest them to derive from our base class if they don't have set_hatch_color?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? On the draw method side we are ok duck-typing and the gc objects should belong to the backends so they should free to implement how ever they want.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just that it'd be an easy fix to get this working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this particular case, it seems better practice than duck typing :)

Copy link
Member

@NelleV NelleV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I am still reviewing this pull request, but I think I'll need some time to get around the code.)

@@ -2210,14 +2210,14 @@ def alpha_cmd(self, alpha, forced, effective_alphas):
name = self.file.alphaState(effective_alphas)
return [name, Op.setgstate]

def hatch_cmd(self, hatch):
def hatch_cmd(self, hatch, hatch_color):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain this extra argument instead of using self._hatch_color?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the way the pdf backend deals with the fact that internally pdf's have a stack-based graphics context so when we change the gc in the draw methods, the delta method is used to determine what is different between the 'current' gc and the 'gc' that was just passed in. The way that method works is by checking a bunch of internal state and if it needs to be updated emit some commands to the pdf file. hatch_cmd is what generates the hatch commands. To tell if we need to change the hatch we need to check both _hatch and _hatch_color and then all of the parameters you check are passed into the command function (see L2323 ish). And the instance of the gc that the command methods are bound to is the 'old' gc, not the 'new' gc so we have to inject it this way.

It is possible that the pdf backend could be cleaned up, but that is a much bigger project.

sorry this is rambley, but it took me a while to sort this out last night.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel the same way 😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this is made more complicated by how we implement hatching in pdf: it replaces the fill color with a named pattern. I think the backend_pdf changes are correct, and you added tests for the new functionality so we should be fine.

gc.set_hatch_color(self._hatch_color)
except AttributeError:
# if we end up with a GC that does not have this method
warnings.warn("Your backend does not support setting the "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we suggest them to derive from our base class if they don't have set_hatch_color?

@tacaswell
Copy link
Member Author

force-pushed to remove some test-thrashing + add docs.

Copy link
Member

@NelleV NelleV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks ok to me, but I have to say that I am very happy that there are tests on this section of the code. It also seems very convoluted, so an additional careful review is in order.

@NelleV NelleV changed the title [MRG] FIX: Restore hatch color tracking edge color [MRG+1] FIX: Restore hatch color tracking edge color Jan 29, 2017
to color the hatches.

In the future there may also be ``hatch_linewidth`` and
``hatch_density`` related methods added. It is encouraged, but not
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NelleV Added the 'please derive from us' verbiage here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you canceling by hand the old travis-ci tests or have we activated the new beta feature to cancel tests on PRs if a newer version exists?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am canceling them by hand.


The color of the lines in the hatch is now determined by

- If an edge color is explicitly, use that for the hatch color
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'is explicitly set'

Copy link
Contributor

@dopplershift dopplershift left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pending CI success.

@QuLogic QuLogic changed the title [MRG+1] FIX: Restore hatch color tracking edge color FIX: Restore hatch color tracking edge color Feb 6, 2017
@QuLogic QuLogic merged commit d63c95d into matplotlib:v2.0.x Feb 6, 2017
@tacaswell tacaswell deleted the fix_hatch_color branch February 6, 2017 22:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants