Skip to content

Navigation Menu

Sign in
Sign up

Lock window size in renders - #273

Open
BorniaPedro wants to merge 2 commits into
camUrban:main from
BorniaPedro:issue-265-bug-resizing
Open

Lock window size in renders #273
BorniaPedro wants to merge 2 commits into
camUrban:main from
BorniaPedro:issue-265-bug-resizing

Conversation

@BorniaPedro

@BorniaPedro BorniaPedro commented Aug 7, 2026 •
edited by camUrban
Loading

Copy link
Copy Markdown
Contributor

Description

Locks the render window size in draw and animate through a two-layer strategy using a VTK ConfigureEvent observer during interactive phases and explicit SetSize re-assertions during non-interactive rendering passes.

Motivation

Dragging, maximizing, or tile-snapping the render window after creation caused screenshots to capture at the resized live window dimensions while text sizes and line widths remained scaled to the initial requested window_size. Additionally, window resizes during the rendering loop of animate resulted in frames of varying dimensions, causing webp.save_images to fail deep in its CFFI layer with an AttributeError: cdata 'struct WebPAnimEncoder *' points to an opaque type. Enforcing the requested window size in both interactive and rendering phases guarantees that saved outputs consistently match the requested dimensions and styling scale.

Relevant Issues

Fixes #265

Changes

  • Added a ConfigureEvent observer to the interactor in draw and animate to snap the render window back to the requested dimensions via SetSize upon OS-level resizes.
  • Re-asserted SetSize on the render window prior to taking the screenshot in draw and before rendering each frame in animate.

Dependency Updates

None.

Change Magnitude

Minor: Small change such as a bug fix, small enhancement, or documentation update.

Checklist (check each item when completed or not applicable)

  • I am familiar with the current contribution guidelines.
  • PR description links all relevant issues and follows this template.
  • My branch is based on main and is up to date with the upstream main branch.
  • All calculations use S.I. units.
  • Code is formatted with black (line length = 88).
  • Code is well documented with block comments where appropriate.
  • Any external code, algorithms, or equations used have been cited in comments or docstrings.
  • All new modules, classes, functions, and methods have docstrings in reStructuredText format, and are formatted using docformatter (--in-place --black). See the style guide for type hints and docstrings for more details.
  • All new classes, functions, and methods in the pterasoftware package use type hints. See the style guide for type hints and docstrings for more details.
  • If any major functionality was added or significantly changed, I have added or updated tests in the tests package.
  • Code locally passes all tests in the tests package.
  • This PR passes the ReadTheDocs build check (this runs automatically with the other workflows).
  • This PR passes the ascii-only, pre-commit-hooks, and zizmor GitHub actions.
  • This PR passes the lint job of the CI GitHub action.
  • This PR passes the test jobs of the CI GitHub action.

camUrban reacted with thumbs up emoji
Copilot AI balanced review requested due to automatic review settings August 7, 2026 14:52

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

codecov Bot commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.52%. Comparing base (3f82796) to head (eac5a4b).

Files with missing lines Patch % Lines
pterasoftware/output.py 60.00% 4 Missing ⚠️
Additional details and impacted files 
@@ Coverage Diff @@
## main #273 +/- ##
==========================================
- Coverage 94.56% 94.52% -0.04% 
==========================================
 Files 47 47 
 Lines 9144 9154 +10 
==========================================
+ Hits 8647 8653 +6 
- Misses 497 501 +4

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

camUrban force-pushed the issue-265-bug-resizing branch from 9e35ddf to eac5a4b Compare August 8, 2026 23:02
@camUrban camUrban changed the title (削除) [BUG] Lock render window size in draw and animate (削除ここまで) (追記) [BUG] Lock window size in renders (追記ここまで) Aug 8, 2026
@camUrban camUrban added the bug Something isn't working label Aug 8, 2026

Copy link
Copy Markdown
Owner

Hi @BorniaPedro. I'm a bit busy with work at the moment, so I won't be able to review this until next week. Thank you for putting in the time to contribute, it means a lot!
BorniaPedro reacted with thumbs up emoji

@camUrban camUrban left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Hi @BorniaPedro. Apologies for the delay in getting a review out for this PR. I think you did a great job implementing what I suggested in #265, but interacting with this method made me re-think the approach. The main issue with my spec is that some methods of re-sizing windows (e.g., maximizing and snapping) are unobservable to PyVista. Even if we made a workaround, I think it's very likely there will be some edge case on some OS that we don't or can't cover.

I think a better approach may be to just render the saved scene off-screen, where we can specify the exact window size without any interference. This does leave an open question: should still show the rendering frame-by-frame of the preview render? If a user manually re-sized, it will look slightly different than what is saved, and it costs another scene creation per-frame. However, if we drop it, that might surprise users or make the function appear to be frozen. Perhaps a middle ground approach would be to display a text message that the animate render is in progress, while keeping the preview window open, frozen on the preview frame. What are your thoughts?

If you are interesting in working on whatever method we settle on, feel free to continue implementing it in this PR. No pressure if not! Either way, thank you for the work you've put in thus far.

@camUrban camUrban changed the title (削除) [BUG] Lock window size in renders (削除ここまで) (追記) Lock window size in renders (追記ここまで) Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot
Copilot review effort, defaults to Balanced
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@camUrban camUrban camUrban requested changes

Requested changes must be addressed to merge this pull request.

Labels

bug Something isn't working

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Resizing the render window mid-session breaks draw's styling and crashes animate's save

AltStyle によって変換されたページ (->オリジナル) /