Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Make RendererCairo auto-infer surface size. #22004

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
Jun 23, 2022

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Dec 18, 2021

This avoids a redundant set_width_height on the caller side, and
prevents the width/height from getting out of sync from the actual
surface size.

Followup to #21981, which conveniently introduces a new API whose
semantics we can still modify :)

PR Summary

PR Checklist

Tests and Styling

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

  • New features are documented, with examples if plot related.
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).

This avoids a redundant set_width_height on the caller side, and
prevents the width/height from getting out of sync from the actual
surface size.
@QuLogic
Copy link
Member

QuLogic commented Dec 21, 2021

It seems like all the cases you've changed had the size available, and the set_context calls are only there, so why do we need to go to the trouble to infer the size instead of passing it in as another argument?

@anntzer
Copy link
Contributor Author

anntzer commented Dec 21, 2021

Mostly, this was motivated by the hidpi changes in gtk3/4agg, where having to fiddle with the dpi scale seems a bit inelegant, when the info is in fact already carried by the context.
It also seems strange to have two APIs (set_ctx_from_surface/set_context and set_width_height) where calls to the first always must be followed by a call to the second, and the args to the second call are in addition completely determined by the first.

@anntzer anntzer added this to the v3.6.0 milestone Mar 26, 2022
@anntzer
Copy link
Contributor Author

anntzer commented Mar 26, 2022

Milestoning as 3.6, as this modifies the semantics of an API introduced in #21981 for 3.6.

@timhoffm
Copy link
Member

@oscargus is there a reason you approved but did not merge? Our policy is that PRs need two positive reviews. With giving you review permissions we also trust you to push the merge button if the two approvals are there.

@oscargus
Copy link
Member

I may not recall exactly, but I believe that it wasn't clear to me if the query from @QuLogic was settled or not. With the assumption that two approvals may not override a concern.

@timhoffm
Copy link
Member

timhoffm commented Mar 28, 2022

I believe that it wasn't clear to me if the query from @QuLogic was settled or not. With the assumption that two approvals may not override a concern.

That's a valid point. In that case I suggest to explicitly mention the open issue, so that it's clear what is still missing for the merge, e.g.

LGTM. @QuLogic is your question reasonably addressed by @anntzer's comment?

or

Approved modulo @QuLogic's comment.

@oscargus
Copy link
Member

In that case I suggest to explicitly mention the open issue

Fair enough.

I try that now then: @QuLogic are you OK with merging?

(Reading the code again, it may make sense to factor out a method, _get_context_size or something similar, for readability, but not required.)

@anntzer anntzer added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label May 27, 2022
@anntzer
Copy link
Contributor Author

anntzer commented May 27, 2022

Marking as RC as this modifies a new API for mpl3.6 (so it's better to do this with no intervening deprecation), and there's at least one user that would benefit from this at https://discourse.matplotlib.org/t/draw-plot-into-existing-cairo-context/22687.
@QuLogic Any thoughts here?

@jklymak jklymak requested a review from QuLogic June 2, 2022 12:30
@jklymak
Copy link
Member

jklymak commented Jun 23, 2022

ping @QuLogic again - this is waiting for your OK....

@QuLogic QuLogic merged commit 71cb651 into matplotlib:main Jun 23, 2022
@anntzer anntzer deleted the cairoinfersize branch June 24, 2022 05:36
@anntzer anntzer mentioned this pull request May 12, 2023
2 tasks
QuLogic added a commit to QuLogic/matplotlib that referenced this pull request Jun 25, 2024
With GTK3, the Cairo surface we get is for the whole window, which means
the automatic size inference from matplotlib#22004 gets the wrong size. For the
GtkDrawingArea, the Cairo context is aligned and clipped to the widget,
so nothing goes out-of-bounds. However, since the Cairo renderer flips
the origin using the height in the calculation (which is, for the
window, bigger than the drawing widget), everything is drawn lower than
it should.
@QuLogic QuLogic mentioned this pull request Jun 25, 2024
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend: cairo 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