Repository navigation
slightly imprecise tick positioning #7341
Description
plt.gca().set(xlim=(1e-2, 50), ylim=(3e-3, 1), aspect=1, xscale="log", yscale="log", xlabel="foo", ylabel="bar")
tight_layout(rect=(0, 0, .85, 1))
save as png.
2.0b4:
All the y ticks overlap with the spine, and one at the very bottom seems misaligned.
The leftmost and rightmost x ticks seem misaligned.
master:
The y tick at the very bottom and the rightmost x tick seem misaligned.
Activity
QuLogic commentedon Oct 24, 2016
Left/right or up/down?
anntzer commentedon Oct 24, 2016
As of master, the bottommost y tick is too much to the bottom, and the rightmost x tick too much to the right... no?
QuLogic commentedon Oct 25, 2016
It's a bit different:
The top row in this figure shows the y-ticks; the lowest tick is actually higher than the other two. The left column in this figure (except the top row, of course) shows the x-ticks; they're a bit more complicated.
That being said, I personally think (and have said elsewhere) that the y-ticks are all too low. That plus the movement in the x-ticks point to ignoring the super/subscripts for alignment.
When comparing the
masterand 2.0b4 images you posted, there is no difference in text location. There is a change in the location of the ticks on the y-axis including, for some reason, the left-most x-tick; they are all one pixel to the right on 2.0b4. This may be a bug.WeatherGod commentedon Oct 25, 2016
Wasn't there a recent bug report where we noticed something more extreme
like this? And the amount that it deviated varied as one resized the window?
On Mon, Oct 24, 2016 at 10:38 PM, Elliott Sales de Andrade <
[email protected]> wrote:
QuLogic commentedon Nov 15, 2016
I don't understand why your figures are only 472px high. When I try to run it on v2.0.0b4, they come out 640x480.
anntzer commentedon Nov 15, 2016
I actually can't reproduce it anymore. I think it may be related to the fact that I swapped from using the (somewhat buggy) Intel graphics driver to kernel modesetting.
anntzer commentedon Dec 6, 2016
Actually I can reproduce the issue again (both 2.0.0b4 and rc1).
WeatherGod commentedon Dec 6, 2016
tacaswell commentedon Dec 7, 2016
@WeatherGod almost certainly
attn @mdboom
tacaswell commentedon Jan 3, 2017
@efiring and I spent a good while looking at this today. The underlying issue is that we draw the ticks in Agg through the marker code path. In that code path we a) rasterize the marker exactly once b) we 'stamp' that raster image onto the canvas at the nearest pixel to where the marker should go. This is done for performance reasons (rather than re-calculating the anti-aliasing every time) and to make sure that every maker looks the same (rather than being of slightly different pixel widths and darknesses due to AA).
The extreme issue at the edges seem to have been addressed and the 'jitter' you can see my slowly resizing the figures is present in 1.4.3 (so we have not broken it recently).
If you look at horizontal lines through the OP here with slightly varied figure widths you can verify that any given tick is only ever shifting by a single pixel at a time, but different pixels shift at different widths and some of the gaps are of the order of 10px so you definitely can pick up on a single pixel shift.
I think we have two courses forward here:
We need to look at the speed trade off of doing 1 vs the complexity of doing 2 (which would have to be done in the c++ layer).
I think that making all of the markers and ticks a bit bigger has made these long standing issues more readily apparent, but not actually created or made them worse.
Punting this to 2.1.
attn @mdboom
15 remaining items
anntzer commentedon Mar 29, 2018
@afvincent issue should be fixed in mplcairo master (just pushed it).
afvincent commentedon Mar 29, 2018
🐑 I think I am using the pip version of mplcairo ^^. I'll try to give a shot at the master one in a while.
anntzer commentedon Mar 29, 2018
Just put up a new wheel build of master at https://github.com/anntzer/mplcairo/releases (under "nightly"), so you can just download that wheel and install it manually.
afvincent commentedon Mar 29, 2018
@anntzer Just installed the nightly wheel and indeed the tick positioning (especially for the left “0” and the top “9”) looks better in the pcolormesh example.
(So I guess that the score is now more 0-1 than 0.5-0.5 in the Agg-mplcairo contest ^^)
ImportanceOfBeingErnest commentedon Mar 29, 2018
The "(With mplcairo) After" case has the same strangely aligned yticklabels as before, right? Also it has a grey line on top of the image. In any case what was the reason mplcairo cannot be used with python2? (I suppose that's the reason not to include it right now?)
anntzer commentedon Mar 29, 2018
AFAICT the y ticks are "perfectly" aligned in the "mplcairo after" case (well there's a bit of antialiasing but it's at the same level on the ticks and on the gridlines). What makes you think they're misaligned? (I'm genuinely curious, perhaps I'm missing something...)
mplcairo doesn't work with Py2 because I don't care enough about Py2 to have any interest in supporting that...
If there is interest in merging mplcairo in Matplotlib I'm fine with that, but right now I'm perfectly happy with having it a separate project -- it's not as if installing it from PyPI and using it was particularly difficult.
ImportanceOfBeingErnest commentedon Mar 29, 2018
@anntzer It often seems as if you are promoting this as an alternative to the Agg renderer. But as long as it is not part of the library it's not really helpful in solving any issue here.
FYI, the misaligned labels I was refering to (hidden not to distract from the main issue here)
It seems the misalignment is larger in the mplcairo case than in the Agg case.
anntzer commentedon Mar 30, 2018
Oh sorry, I misread you: you were mentioning the tick labels, not the ticks themselves. Yes, I need to look into that.
Alternate renderers are relevant even if you don't use them because they help shining light on choices that have not been documented but have to be made (e.g., in this case, snapping: long lines look ok if not snapped, but short ticks do not; but if we only snap the ticks, then they end up misaligned).
You are of course free to use the renderer you want / that solves the problem that bothers you; mplcairo is PyPI-installable so it is relatively straightforward to install (if you're using Py3... and not on OSX as I don't really understand some details of the compilation model there). FWIW I have already used it in publication material.
anntzer commentedon Mar 30, 2018
The text alignment is "mostly" fixed now.
WeatherGod commentedon Mar 30, 2018
@ImportanceOfBeingErnest, the main reason why mplcairo is not in matplotlib yet is because we want to see it exercised more before incorporating it. There are also some other reasons such as the need for a very recent C++ compiler to build it from source. While I am pretty much convinced that cairo will be the future renderer for matplotlib, it will take some time to make that transition.
For one thing, AGG actually only does a subset of what cairo can do, so swapping them out actually involves a little bit more work than just switching the rasterizer. Also, look at how much the name AGG is embedded into our matplotlib vocabulary. How are we going to transition people who set their backends to "WxAgg"? We also use AGG library for handling imshow().
Updating the test suite will also take time. Since mplcairo actually improves things in many cases, every changed baseline image will have to be approved. That is a painstaking process to make sure that the changes are 1) expected, 2) better, and 3) no other unexpected changes.
anntzer commentedon Mar 30, 2018
@WeatherGod Thank you for explaining the situation much better than I did.
github-actions commentedon Apr 1, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!