Status: known issue, upstream, maintainer-filed to track it. This is a Windows window-manager bug, not something Fractadyne can fully fix, but the app has been changed so it no longer makes things worse or crashes because of it.
What happens
On Windows 11, dragging the window between two monitors that use different display scaling (for example 150% and 100%) makes the window grow. Each crossing multiplies the window size by the ratio of the two monitors' scale factors, in both directions, so repeated crossings inflate it steadily.
Why it is upstream, not ours
The scale change is applied twice, a fraction of a second apart, by the layer beneath the app. It reproduces in the underlying windowing library independently of Fractadyne, and matching reports are open there:
The egui report is filed against a version newer than the one Fractadyne ships, and it is still open there, so upgrading is not the fix.
What Fractadyne does about it
- The size ceiling the growth used to crash into (an internal limit well below what the GPU actually supports) has been removed, so the window no longer dies mid-drag.
- After a monitor crossing settles, the app restores the window to its pre-crossing size, undoing the growth. It only ever shrinks back, and only for about a second after a scale change, so a window you resize yourself is never fought.
FRACTADYNE_TRACE=dpi logs scale factor and logical/physical size on every real change, so a recurrence produces evidence. A healthy crossing holds the logical size and rescales only the physical size by the new factor; the defect is the physical size ratcheting up beyond that.
How you can help
- If the window still grows across crossings on a current build, run with
FRACTADYNE_TRACE=dpi and attach the log lines around the crossing, with your two monitors' scale percentages.
- One untested hypothesis worth a data point:
FRACTADYNE_NO_MIN_SIZE=1 disables the app's minimum-window-size constraint, which is one suspected contributor. If setting it changes the behaviour on a two-monitor setup, that is a useful result either way.
For maintainers
Tracked in TODO.md ("MOVING THE WINDOW BETWEEN MONITORS…"); headroom and pre-crossing size restore landed in v0.2.40-beta.61–66. Reproducible only on a real dual-monitor, mixed-DPI setup.
Status: known issue, upstream, maintainer-filed to track it. This is a Windows window-manager bug, not something Fractadyne can fully fix, but the app has been changed so it no longer makes things worse or crashes because of it.
What happens
On Windows 11, dragging the window between two monitors that use different display scaling (for example 150% and 100%) makes the window grow. Each crossing multiplies the window size by the ratio of the two monitors' scale factors, in both directions, so repeated crossings inflate it steadily.
Why it is upstream, not ours
The scale change is applied twice, a fraction of a second apart, by the layer beneath the app. It reproduces in the underlying windowing library independently of Fractadyne, and matching reports are open there:
The egui report is filed against a version newer than the one Fractadyne ships, and it is still open there, so upgrading is not the fix.
What Fractadyne does about it
FRACTADYNE_TRACE=dpilogs scale factor and logical/physical size on every real change, so a recurrence produces evidence. A healthy crossing holds the logical size and rescales only the physical size by the new factor; the defect is the physical size ratcheting up beyond that.How you can help
FRACTADYNE_TRACE=dpiand attach the log lines around the crossing, with your two monitors' scale percentages.FRACTADYNE_NO_MIN_SIZE=1disables the app's minimum-window-size constraint, which is one suspected contributor. If setting it changes the behaviour on a two-monitor setup, that is a useful result either way.For maintainers
Tracked in
TODO.md("MOVING THE WINDOW BETWEEN MONITORS…"); headroom and pre-crossing size restore landed in v0.2.40-beta.61–66. Reproducible only on a real dual-monitor, mixed-DPI setup.