Maximizing window is not resizing the stage after manual window resize on native targets (Windows, Hashlink)

[twilson90]

If I resize the window manually by dragging the edges, then maximize, the contents of the window become fixed to the bottom left corner of the window and the content is clipped to the previously set window width and height.
Not sure exactly when the bug was introduced but it's not present on the last release (8.3.2)

[twilson90]

Oops, my mistake. It turns out it was a bug in my fork of OpenFl. The DisplayObject __getLocalBounds had been slightly modified and was returning an incorrect value for the Stage / root (not sure which).

[twilson90]

Ignore previous post, I found a bug in my OpenFl fork, fixed it and the issue went away - turns out I was still using the previous Lime release when I tested.
Issue is still present in development branch.

[joshtynjala]

the contents of the window become fixed to the bottom left corner of the window

One of my clients recently reported the same issue to me last week. They weren't sure how to reliably reproduce it, though.

I don't seem to be able to reproduce on Fedora Linux with KDE Plasma. However, I plan to try your steps on my Mac or Windows machines too.

[dimensionscape]

Investigating it. This is likely due to recent changes made to continue rendering while we process window events .

[joshtynjala]

I can't seem to reproduce on Windows 11 (25H2) either. Latest develop branches of both Lime and OpenFL. Tried neko, hl, and windows targets. I click and drag the bottom-right corner of the window to resize larger or smaller. Then, I click the maximize button. Tried with both PiratePig and with the Feathers UI components-explorer. The stage resizes correctly on both.

[dimensionscape]

@twilson90 I also couldn't reproduce. I assume there are some missing reproduction steps, particularly in how you might be handling content resize and scale mode.

[twilson90]

Sorry, I should've provided a reproducable example.

I managed to recreate it in PiratePig by simply adding to the project.xml:

<window fps="60" vsync="true" />

The FPS value has to be 60 or over to trigger the bug for me, it might be different for others. My display's refresh rate is 60 but I doubt it's pertinent.
With these specific conditions, Stage.stageWidth and stageHeight do not get updated when the window is maximized.

Somewhat related to this issue - I'm also noticing that when resizing the window manually with these specific attributes there's some unusual frame pacing which isn't present without them.
My frame time graph should remain relatively flat and in the middle (green) but it goes like this when resizing:

The vsync toggle appears to be the culprit here, and it's doing nothing beneficial in windowed mode, it seems to only serve its purpose in fullscreen mode, so for now I've turned it off.
With vsync off it resizes correctly on maximize and the frame pacing is good when resizing.
So perhaps flip the vsync switch in SDL only when entering/exiting fullscreen? Not sure.

Not to digress even further, but the whole frame pacing issue I encountered (#2026) remains unresolved. It's improved in the latest changes but I still can get it to go out of step with enough messing about. Anyway, I'll look into that further and maybe start another issue regarding that.

[dimensionscape]

Okay, there's a lot to unpack here.

Somewhat related to this issue - I'm also noticing that when resizing the window manually with these specific attributes there's some unusual frame pacing which isn't present without them.

Some uneven pacing while manually moving/resizing a native window is expected. On Windows, the OS enters a modal sizing/moving loop, and Lime now tries to continue pumping resize/render updates during that loop. Previously, the framebuffer generally would not update during live moving/resizing at all, so the behavior is different by design.

That said, the maximize size not reaching Stage.stageWidth / stageHeight is a separate concern. If the final resize event is being missed or suppressed after maximize, that would be a real bug.

I still can get it to go out of step with enough messing about

There are limits to what Lime can guarantee here. If the app, OS, driver, compositor, or runtime stalls long enough to miss the frame budget, frame timing will not remain perfectly regular. HXCPP also uses a stop-the-world GC, so latent allocation pressure from Lime/OpenFL/user code can still cause occasional hitches, especially on slower hardware.

So I would separate occasional hitches under stress from a deterministic resize/maximize bug.

The vsync toggle appears to be the culprit here, and it's doing nothing beneficial in windowed mode, it seems to only serve its purpose in fullscreen mode

I don't think that's the right conclusion. Windowed vsync behavior is platform/driver/compositor-dependent, but it is not inherently useless in windowed mode, and I don't think disabling SDL vsync outside fullscreen is the right fix.

The useful detail is that fps="60" + vsync="true" changes how the SDLApplication loop is paced. When real vsync is active and the requested frame rate is at or above the display refresh rate, Lime lets presentation/vsync drive the loop instead of applying its own fixed sleep interval. That may be interacting with the Windows live-resize path.

I haven't been able to reproduce the maximize issue locally yet, but based on your repro conditions, the part I would investigate is whether the Windows resize-event bookkeeping can suppress the final size event after maximize. If that happens, OpenFL would keep the previous stage size even though the native window was maximized.

[twilson90]

Thanks for the insight.
The only thing I should clarify in case it wasn't clear - the spikey frame pacing when I resize the window is only present when I export with vsync + fps=60, without either of those it's nice and smooth when I resize. So I think there is a problem there as well, but that's a separate issue.

[joshtynjala]

managed to recreate it in PiratePig by simply adding to the project.xml:
<window fps="60" vsync="true" />

Just making a note that I can reproduce this one on Windows with native targets. I could not on macOS or Linux.

Some observations:

Resizing the window once by dragging an edge is necessary, as described. When you maximize the window, the contents are aligned to the bottom left corner at the same size that they were before maximizing.

If you restore the window from maximized to normal, resizing by dragging the edge works correctly.

Maximizing again reproduces the issue again, but the content remains the same size from the most recent time that an edge was dragged.

[joshtynjala]

A couple more things:

I also confirm that it reproduces with Lime develop, but not 8.3.2.

When maximizing the window, stage.window.onMaximize is dispatched, but stage.window.onResize is not.