Skip to content

subplots animation example is broken on OS X with qt4agg #6335

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

Closed
efiring opened this issue Apr 25, 2016 · 7 comments · Fixed by #6339
Closed

subplots animation example is broken on OS X with qt4agg #6335

efiring opened this issue Apr 25, 2016 · 7 comments · Fixed by #6339

Comments

@efiring
Copy link
Member

efiring commented Apr 25, 2016

mpl master, python 3.5 from Anaconda on OSX Mavericks:

With the qt4agg backend, when I execute python subplots.py or pythonw subplots.py on the command line, only one of the three axes has anything drawn in it, and which one gets the line is random from one execution to another (although I never saw the upper right one get it). Furthermore, resizing the window does not correctly redraw the figure.

However, the shiny new implementation of macosx with Agg works perfectly provided it is invoked with pythonw.

I can't test tkagg because I can't get that backend to work at all with Anaconda.

@tacaswell
Copy link
Member

I can not reproduce this on linux.

@tacaswell tacaswell added this to the 2.0.1 (next bug fix release) milestone Apr 26, 2016
@mdboom
Copy link
Member

mdboom commented Apr 26, 2016

I can confirm this on a Mac. I think I'll try to git bisect.

@mdboom
Copy link
Member

mdboom commented Apr 26, 2016

Broken on 1.5.1 and 1.4.3 as well. Starting to think this never worked.

@dopplershift
Copy link
Contributor

dopplershift commented Apr 26, 2016

I don't understand why the bug is OSX-only if the fix is in Qt4Agg....

@mdboom
Copy link
Member

mdboom commented Apr 26, 2016

Even though it's all Qt, the GUI loop in OSX is more asynchronous than on Linux. When a draw is requested on Qt/X11, it's more likely to occur sooner, before other draws are queued. On the Mac, it tends to delay drawing more, so multiple calls get queued up between updates to the screen. This has been an issue for the native macosx backend as well.

@tacaswell
Copy link
Member

I suspect that this is related to the general difficulties in getting to the draw loop on OSX. In the OSX backend we deal with them our selves, but in the Qt case they are dealing with the same issue and we are seeing and edges of it poking out.

@mdboom
Copy link
Member

mdboom commented Apr 26, 2016

In the OSX backend we deal with them our selves

Well, there, we deal with it by always doing a full blit, which is a lot simpler, and barely measurably slower. We could also try to do that for Qt and see how it works out.

tacaswell added a commit that referenced this issue May 2, 2016
tacaswell added a commit that referenced this issue May 2, 2016
@QuLogic QuLogic modified the milestones: 2.0 (style change major release), 2.0.1 (next bug fix release) May 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants