Nice!

Will this make any difference to the requirement for a Python framework build by any chance? It's a significant pain point.

Unfortunately, this makes no difference with respect to a framework build. Anaconda has a nice workaround to make a build that "works both ways" (it's not really a framework build, but it has a .app wrapper). I think overtime other distros will probably adopt a similar approach.

Wow! Works on a Retina with Mavericks! Sharp and snappy!
Will this also make it possible to add restore_region() and copy_from_bbox to the canvas, so that animations (e.g. double_pendulum_animated) and widgets (e.g. lasso_selector_demo) will work?

Yes -- I was just reminded that restore_region() doesn't work on macosx backend. It should be pretty straightforward to add that now.

Except wasn't there fundamental conflicts in the design of the macosx
backend that prevented this? I remember very detailed explanations on the
differences between macosx and gtk/qt drawing models as the basis for that
conflict.

On Fri, Mar 18, 2016 at 7:12 AM, Michael Droettboom <
notifications@github.com> wrote:

Yes -- I was just reminded that restore_region() doesn't work on macosx
backend. It should be pretty straightforward to add that now.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6178 (comment)

Seems to work really great

@efiring I think restore_region and copy_from_bbox will work with agg. With the native implementation, restore_region and copy_from_bbox needed to be done from inside the callback function during the event loop to satisfy Apple's API requirements. As agg has its own image buffer, restore_region and copy_from_bbox can now be done independently of the event loop.

Animations now work. It's a bit less efficient than it could be -- the blitting to the Agg buffer is for specific rectangles of the image, but the blitting of the figure to the window is always still the entire figure. That could probably be made to work, but I'm not sure how much benefit it would really have -- the real benefit of the animation code is to not draw (vectorize) more than we have to. Blitting is pretty cheap relative to those things.

My animation code works at good speed with this PR - thanks very much for doing this.

There is still a problem with lasso_selector_demo.py. The curve is drawn displaced from the cursor by a large fraction of the window size, and everything seems to being getting selected.

There is still a problem with lasso_selector_demo.py. The curve is drawn displaced from the cursor by a large fraction of the window size, and everything seems to being getting selected.

It looks like mouse events aren't being properly scaled by the device scale.

I'm of two minds on where this should be milestoned as well. It certainly makes it easier to have consistent look-and-feel across the major backends, which is what 2.0 is "about". But I can see it either way.

It would be great to have this in for 2.0 - it looks like it will make the OSX backend easier to use, and less puzzling to people reading examples and documentation for other backends.

Given all of the bugs that this addresses, an argument can be made for putting it in 1.5.x! And given how long it is taking us to get 2.0 out, I think that waiting even longer, for 2.1, would be a mistake.
Some more comprehensive testing is still needed, most likely, in case there are still problems like the one you just fixed; but after that, the sooner it can get in, the sooner we can all breath a sigh of relief.

Considering how large #5718 was, and it still got into 2.x, I don't see a problem including this PR too.

@mdboom I tried to cherry-pick this to v2.x, but failed--would you take care of that, please?

Cherry-picked to 2.x as e981e1e

Hi, apologies for asking a 'rookie' question over here. I recently migrated from linux to a retina mac and found the macosx backend to be very slow at rendering stuff. other backends either don't work or display very low resolution graphics. if I understood correctly this is part of the issue that was fixed here.
I have cloned the matplotlib repository and installed it as indicated in the readme, but once I try to import the peplos module it complains about python not being installed as a 'framework'.
I understand that this has to do with virtual environments, but nothing more; I have an Anaconda installation and tried calling 'pythonw -m qtconsole' but with no success. It does however work fine from ipython (jupyter), albeit still being slow in displaying the graphics.

If anyone could give me a suggestion of how to make the qtconsole import matplotlib fine I would greatly appreciate it, thanks!