fix: window came up short, clipping the bottom of the interface #22
No reviewers
Labels
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
BlackLobster/Client!22
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/ui-scale"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
initApplication read getInsets() straight after setVisible() and sized
the frame from the answer -- but at that point the window manager has
not decorated the window yet, so AWT returns a guess. Under KWin the
guess is top=25 where the real title bar is top=56, and the guess is
scaled too, so at uiScale 2 it is top=12. The frame is sized from it and
comes up short by the difference: 26px at 1x, 42px at 2x.
The canvas is added to the frame's default BorderLayout, so it is
stretched to that short content area rather than clipped by it -- the
bottom rows of the interface (chat entry, chat tabs, orb row) are never
drawn, and there is nothing to scroll to. Pre-existing; doubling the
scale doubled the loss and made it obvious.
Frame sizing now targets a CONTENT area of exactly canvasWidth x
canvasHeight: awaited briefly before the first paint (the real insets
land ~15ms later), then re-applied by mainredrawwrapper's existing
periodic canvas pass. Each distinct target is requested once, so a
window manager that refuses a size is not fought with forever.
Measured under KWin at uiScale 2: content area 927 -> 1006 device px.