8000 FIX: add check if the renderer exists by tacaswell · Pull Request #5060 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

FIX: add check if the renderer exists #5060

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 1 commit into from
Sep 14, 2015

Conversation

tacaswell
Copy link
Member

There exists a path where paintEvent can be called before the first time
that draw has been called. This results in an exception because the
call to FigureCanvasAgg.draw(self) is what create the renderer
attribute on the canvas.

Closes #5058

@astrofrog @efiring @pwuertz

# be called to create the renderer and to render the initial view
# of the figure
if not hasattr(self, 'renderer'):
FigureCanvasAgg.draw(self)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is probably unsafe. paintEvent is usually called by a different thread, not from main thread the matplotlib code is running in. Calling draw here may cause concurrent access to the matplotlib figure, which is not thread safe.

Copy link
Member Author

Choose a reason for hiding this comment

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

Change to return as you suggested.

@efiring
Copy link
Member
efiring commented Sep 13, 2015

Works for me.

There exists a path where paintEvent can be called before the first time
that `draw` has been called.  This results in an exception because the
call to `FigureCanvasAgg.draw(self)` is what create the renderer
attribute on the canvas.
@astrofrog
Copy link
Contributor

Works for me too 👍

@tacaswell tacaswell added this to the next point release milestone Sep 14, 2015
@tacaswell tacaswell added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Sep 14, 2015
@tacaswell
Copy link
Member Author

I will self merge this later if no one beats me to it.

efiring added a commit that referenced this pull request Sep 14, 2015
FIX: add check if the renderer exists
@efiring efiring merged commit 6b429c9 into matplotlib:master Sep 14, 2015
@efiring
Copy link
Member
efiring commented Sep 14, 2015

Couldn't resist the rare opportunity to beat you to it! I had also given a quick check to the revised version.
However...although this seems to fix the immediate problem, it seems like a hack, suggesting that there is probably a cleaner way to ensure the events are properly sequenced. Maybe someone will be able to suggest such a cleanup.

@tacaswell tacaswell deleted the fix_qt_draw_order branch September 14, 2015 19:56
@pwuertz
Copy link
Contributor
pwuertz commented Sep 14, 2015

I don't think there is much to clean up. You can't control (and shouldn't) when paintEvent is called, so it's perfectly possible that paintEvent is issued while matplotlib hasn't done anything yet. So there is just the question of using hasattr or "properly" initializing FigureCanvasAgg so all its attributes are valid after construction?

@dopplershift
Copy link
Contributor

In principle I agree with you. However, I was seeing this (I think) consistently on OSX, so I'm not positive it's race condition rather than poor ordering.

@tacaswell
Copy link
Member Author

On the other hand I never saw this on linux which makes me worried that if it is ordering, not a race condition, it is at a layer we can not easily control.

@pwuertz
Copy link
Contributor
pwuertz commented Sep 14, 2015

Well, I'm sure that there is a certain kind of order and consistent behaviour on each specific platform. But you could call it a non-random race condition because you don't know and cannot rely on the way Qt is implemented on a system. It might as well change on the next release. I think not making assumptions regarding the timing of paintEvent is the safest path.
Also the point in not drawing Agg within paintEvent. Qt might use a separate thread for the gui and for rendering, but that isn't guaranteed for every platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GUI: Qt 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.

5 participants
0