That is bad. This is maybe related to #2889 ?

Can confirm this on master.

If you set the dpi to 100 it more-or-less works correctly, you can see the corners of the red sequare outside of the edges of the annotation box, but it is in the right place.

That is bad. This is maybe related to #2889 ?

I've not seen the picture, but it is worth noting that the issue there was highlighted by a change which was applied after v1.3.1. Though it could be the same underlying bug, none-the-less.

P.S. A screenshot of the problem:

So the red box is in the wrong place for the plot.

Interestingly, if you don't specify the correct DPI at savefig for PNG, the red box is also in the wrong place. Something is a little fishy there...

@pelson The similarity is (I think) related to using get_extent in one context which creates values based on current screen-space transforms. The values are then saved and get re-used with different screen-space transforms which causes things to be the wrong size/in the wrong place.

The similarity is (I think) related to using get_extent in one context which creates values based on current screen-space transforms.

Agreed. The issue can be seen with all backends with a simple modification to @wronk 's code:

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.image import BboxImage

bboxProp = dict(boxstyle='round,pad=0.3', fill=False, ec='red', linewidth=8)

ax = plt.axes()
midBox3 = ax.annotate(r'$j_{N-1}$', xy=(0, .5), xycoords='axes fraction',
                      xytext=(0.7, 0.7),
                      textcoords='axes fraction',
                      size=50, ha='left', va='center', bbox=bboxProp,
                      arrowprops=None, color='black')

ax.add_artist(BboxImage(midBox3.get_bbox_patch().get_window_extent,
              data=np.zeros_like(np.atleast_2d(np.arange(256)/256.))))
ax.set_ylim(bottom=-1)
plt.show()

The key is that the red box only appears after the figure has been re-drawn. The change in x/y limit is significant here.

@pelson @efiring @mdboom I am going to punt this and the related issues to 1.5 (at least).

My understanding of the problem here is that artists are being lined up in screen-space (through get_window_extent) and then when things get updated underneath the artists the changes don't propagate. I think any fix for this will be a major overhaul.

I will create an issue to add a note to get_window_extent docs warning that it can lead to this sort of thing.

@tacaswell - do you know if #3054 fixes this issue?

I don't, but should probably check (I left this comment before I found that patch).

This does seem like quite a fundamental problem; a full solution might require a dependency-tracking system. This reminds me of the lazy evaluation system (implemented via a C++ extension) that JDH originally used in mpl.

Is it the case that get_window_extent can be used safely only inside a draw method? And that anything that changes what get_window_extent would yield needs to ensure that every draw method is executed after the change? Is the problem coming from caching the result of a draw, and not declaring the cached result invalid when a transform has changed?

Using get_window_extent can be quite tricky as in the above case.
As it requires a renderer instance, it should be used inside a draw method.
But this is not all. For some artists (e.g., text, annotation), its extent is usually determined after the artist is drawn. Also, extent of some artist depends on extent of other artists. And a dependency-tracking is often manually implemented.

In the above case, gradient calls midBox3.get_bbox_patch().get_window_extent before it is drawn (because of the zorder), thus it ended up in a wrong location. It would have been better if midBox3.get_bbox_patch().get_window_extent somehow automatically update the extent of midBox, but I believe this is not easy to implement within the current framework.

And I agree with Eric that we need some sort of dependency-tracking.

For the current example, here is a work-around. It defines a function that update the extent of midBox3 and pass it to BboxImage.

def annoate_get_window_extent(renderer):
    midBox3.update_positions(renderer)
    Text.update_bbox_position_size(midBox3, renderer)
    rr = midBox3.get_bbox_patch().get_window_extent(renderer)
    return rr

gradient = BboxImage(annoate_get_window_extent,
                     data=np.zeros_like(np.atleast_2d(np.arange(256)/256.)))
ax.add_artist(gradient)

Looking at the code above, I strongly feel that it should be simpler than this though.

I re-milestoned this as 1.5.x as it seems that nothing in behaving incorrectly, just inconveniently. Tacking automatic tracking of changing on to the frame work sounds like it will be a good deal of work (if it is possible) and there is a work-around (which I agree works...BboxImage needs documentation).

@wronk Does the work-around work for you?

That project is on the back burner for me at the moment, but I'll give it a
shot in a week or two and let you know how it goes. Thanks for identifying
the work around though.

On Sat, Jun 28, 2014 at 6:16 PM, Thomas A Caswell [email protected]
wrote:

I re-milestoned this as 1.5.x as it seems that nothing in behaving
incorrectly, just inconveniently. Tacking automatic tracking of
changing on to the frame work sounds like it will be a good deal of work
(if it is possible) and there is a a work-around (which I agree works...
BboxImage needs documentation).

@wronk https://github.com/wronk Does the work-around work for you?

—
Reply to this email directly or view it on GitHub
#2831 (comment)
.

(Encountered this issue while generating a figure for my publication and signed up on github to tell you this)

I tried this on Jupyter notebook and it generated wrong vector figure. When I copied the "same exact code" to IPython console, problem gone :) I don't know why.

@sirenayka Can you be a bit more specific about what code you ran? I suspect the the effect was getting 'lucky' about what order things ran in.

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!

This is a strange one. If I run it as-is, I see nothing in the PDF but the text. If I change the code to save the PNG first, then the PDF starts showing the image, but it disappears from the PNG. If I then change figure DPI to 72 (which matches PDF's internal DPI), then the image moves under the text.

I guess this has to do with #2831 (comment)

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!

I still see the same as reported by @QuLogic in that there is just the text, no box, in the PDF

This "fixes" the problem

   ...: if saveFig:
   ...:     pdfFile = PdfPages(save_fname + 'flowchart_PDF.pdf')
   ...:     plt.savefig(BytesIO(), format='pdf', dpi=fig.dpi)
   ...:     plt.savefig(pdfFile, format='pdf', dpi=fig.dpi)
   ...:     pdfFile.close()
   ...:     plt.savefig(save_fname + 'flowchart_PNG.png', dpi=fig.dpi)
   ...: plt.show()

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!

Re-evaluating this, I think @leejjoon is completely correct. The source of the problem is that for zorder reasons we have to draw the background before the text, but the text does not know how big it is before has been drawn.

Short of implementing a system to automatically detect when we need to render multiple times there are two fixes:

1. do a manually "dummy" save to a BytesIO with the exact same settings as you want to save the output as.
2. use layuot='constrained' or layout='tight' which internally do a dummy render to get all the text sizes so that they can then update the layout.

1. do a manually "dummy" save to a `BytesIO` with the exact same settings as you want to save the output as.

Does this work? I believe not reliably just with a savefig, because it only replaces the canvas temporarily.

If I do:

In [6]: print(ax.transData)
CompositeGenericTransform(
    [...]
        BboxTransformTo(
            TransformedBbox(
                Bbox(x0=0.125, y0=0.10999999999999999, x1=0.9, y1=0.88),
                BboxTransformTo(
                    TransformedBbox(
                        Bbox(x0=0.0, y0=0.0, x1=6.4, y1=4.8),
                        Affine2D().scale(100.0)))))))

In [7]: fig.savefig('test.png', dpi=50)

In [8]: print(ax.transData)
CompositeGenericTransform(
    [...]
        BboxTransformTo(
            TransformedBbox(
                Bbox(x0=0.125, y0=0.10999999999999999, x1=0.9, y1=0.88),
                BboxTransformTo(
                    TransformedBbox(
                        Bbox(x0=0.0, y0=0.0, x1=6.4, y1=4.8),
                        Affine2D().scale(100.0)))))))

the Affine2D().scale(100.0) is the dpi scaling so I won't get my dpi=50 into the window extent ?!?

Another approach would be to use a callable object that explicitly update the position of the text and the patch. This does not require rendering the figure twice

def get_bbox(renderer):
    midBox3.update_positions(renderer)
    midBox3.update_bbox_position_size(renderer)
    return midBox3.get_bbox_patch().get_window_extent(renderer)

arr = np.atleast_2d(np.arange(256)/256.)
bbox_image = BboxImage(get_bbox, data=arr)
ax.add_artist(bbox_image)

Yet another option is to use patheffects. The example code below uses mpl_visual_context module which I created.

from matplotlib.patheffects import Normal
from mpl_visual_context.patheffects import FillImage

bbox_image = BboxImage(midBox4.get_bbox_patch().get_window_extent,
                       data=arr)

midBox3.get_bbox_patch().set_path_effects([FillImage(bbox_image, ax=ax),
                                           Normal()])

Does this work?

My understanding is that in similar cases (passing arg.get_window_extent as a callable referring to something later in the draw order, that artist may move/resize itself as part of the draw, and saving to a vector format) this will work reliably. Because vector backends always set the dpi to 72 (because we need all of the "screen" positions that come out to be in inches) so doing draw_without_render without doing the same won't work. The fist save will get the wrong position for the box, correct the position of the text which is preserved in some state (I'm not entirely sure which state) between draws so in the second draw the box is in the right place and the text recomputes to the same place.

@leejjoon's suggestion will work 100% with only one save, but requires the user to know which methods to call to update the correct state.