Skip to content

Fix scene processor resizing with highdpi/supersampling mode - #2840

Merged
riccardobl merged 3 commits into
jMonkeyEngine:masterfrom
riccardobl:fixscale
Jun 1, 2026
Merged

Fix scene processor resizing with highdpi/supersampling mode#2840
riccardobl merged 3 commits into
jMonkeyEngine:masterfrom
riccardobl:fixscale

Conversation

@riccardobl

@riccardobl riccardobl commented Jun 1, 2026

Copy link
Copy Markdown
Member

Fixes #2838

This pr:

  1. deprecates the unused rescale hook, likely a left over from a previous attempt at implementing high dpi support. Currently unused by the engine and a defacto no-op.

  2. handle resource and swap failures that can happen during fast window rescaling operations

  3. add a resizeWithDefaultFramebuffer flag in ViewPort. When true the viewport will receive with and height values from
    the highdpi/supersampled framebuffer.

SceneProcessors, like FilterPostProcessor, rely on a sort of "hack" where they replace the viewport output framebuffer with their internal one, and then blit it back to the default framebuffer.
The problem is that the scene processors are resized to their own viewport and FilterPostProcessor resizes the viewport (and framebuffer) from its resize hook, so they resize each other recursively.

The only reason this currently working is that FilterPostProcessor used the camera sizes to do the scaling, instead of the viewport output size. This used to work fine before because camera sizes used to be equivalent to the render target size, but this is not true anymore now that we have proper highdpi/scaling support, since camera sizes will be the logical size of the viewport while the underlying render target can be much bigger. Point 3 solves this by making the engine aware of when a viewport wants to track the default framebuffer.

@gemini-code-assist gemini-code-assist Bot 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.

Code Review

This pull request deprecates the rescale method across various classes and contexts, shifting display scale reporting to the reshape method. It also updates FilterPostProcessor and HDRRenderer to initialize using the viewport's render target size rather than the camera's size, introduces a mechanism to track whether viewports should resize with the default framebuffer, and improves window event and swap failure handling in LwjglWindow. However, the refactored cleanup code in Filter and FilterPostProcessor incorrectly attempts to call a non-existent dispose() method on com.jme3.texture.Image objects; these should be updated to use renderer.deleteImage(image) instead.

Comment thread jme3-core/src/main/java/com/jme3/post/Filter.java
Comment thread jme3-core/src/main/java/com/jme3/post/FilterPostProcessor.java
@riccardobl
riccardobl merged commit e6c13b8 into jMonkeyEngine:master Jun 1, 2026
11 checks passed
@yaRnMcDonuts yaRnMcDonuts added this to the v3.10.0 milestone Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Scaling broken in 3.10 beta

2 participants