Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
QuLogic merged 1 commit intomatplotlib:mainfromanntzer:cairoinfersize
Jun 23, 2022

Conversation

anntzer
Copy link
Contributor

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 (andpytest passes).
  • IsFlake 8 compliant (installflake8-docstrings and runflake8 --docstring-convention=all).

Documentation

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

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

It seems like all the cases you've changed had the size available, and theset_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
ContributorAuthor

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.

@anntzeranntzer added this to thev3.6.0 milestoneMar 26, 2022
@anntzer
Copy link
ContributorAuthor

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 commentedMar 28, 2022
edited
Loading

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 reacted with thumbs up emoji

@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.)

@anntzeranntzer added the Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. labelMay 27, 2022
@anntzer
Copy link
ContributorAuthor

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 athttps://discourse.matplotlib.org/t/draw-plot-into-existing-cairo-context/22687.
@QuLogic Any thoughts here?

@jklymakjklymak requested a review fromQuLogicJune 2, 2022 12:30
@jklymak
Copy link
Member

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

@QuLogicQuLogic merged commit71cb651 intomatplotlib:mainJun 23, 2022
@anntzeranntzer deleted the cairoinfersize branchJune 24, 2022 05:36
@anntzeranntzer mentioned this pull requestMay 12, 2023
2 tasks
QuLogic added a commit to QuLogic/matplotlib that referenced this pull requestJun 25, 2024
With GTK3, the Cairo surface we get is for the whole window, which meansthe automatic size inference frommatplotlib#22004 gets the wrong size. For theGtkDrawingArea, the Cairo context is aligned and clipped to the widget,so nothing goes out-of-bounds. However, since the Cairo renderer flipsthe origin using the height in the calculation (which is, for thewindow, bigger than the drawing widget), everything is drawn lower thanit should.
@QuLogicQuLogic mentioned this pull requestJun 25, 2024
2 tasks
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@QuLogicQuLogicQuLogic approved these changes

@timhoffmtimhoffmtimhoffm approved these changes

@oscargusoscargusoscargus approved these changes

Assignees
No one assigned
Labels
backend: cairoRelease criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Milestone
v3.6.0
Development

Successfully merging this pull request may close these issues.

5 participants
@anntzer@QuLogic@timhoffm@oscargus@jklymak

[8]ページ先頭

©2009-2025 Movatter.jp