Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unmapped windows with size constraints need to adjust them for SSDs #3780

Merged
merged 2 commits into from
Feb 26, 2025

Conversation

AlanGriffiths
Copy link
Collaborator

Fixes: #3778

@AlanGriffiths AlanGriffiths requested a review from a team as a code owner February 26, 2025 10:12
@tarek-y-ismail
Copy link
Contributor

So if I understand correctly, for umapped windows (basically, hidden or minimized windows), this assumes they're 640x480? What happens when they're mapped? I assume they can override this size, right?

@AlanGriffiths
Copy link
Collaborator Author

So if I understand correctly, for umapped windows (basically, hidden or minimized windows), this assumes they're 640x480? What happens when they're mapped? I assume they can override this size, right?

The case encountered with Qt was "no buffer submitted yet" + "min & max size set"

@tarek-y-ismail
Copy link
Contributor

The case encountered with Qt was "no buffer submitted yet" + "min & max size set"

Huh, very weird. So I guess the application is telling us to choose a size between the min and max? If so, shouldn't we take that into account when adjusting?

@AlanGriffiths
Copy link
Collaborator Author

Huh, very weird. So I guess the application is telling us to choose a size between the min and max? If so, shouldn't we take that into account when adjusting?

Not weird. Unlike X11 toolkits Wayland ones often commit() before attaching buffers. What was new to us was that the min/max size was set and we were using SSDs.

The existing code only adjusted the min/max size when we also had a size (from the submitted buffer)

@tarek-y-ismail
Copy link
Contributor

The existing code only adjusted the min/max size when we also had a size (from the submitted buffer)

Oh, ho! So this is so we execute these statements?

if (wm_relevant_mods.max_width.is_set())
wm_relevant_mods.max_width.value() += horiz_frame_padding;
if (wm_relevant_mods.max_height.is_set())
wm_relevant_mods.max_height.value() += vert_frame_padding;
if (wm_relevant_mods.min_width.is_set())
wm_relevant_mods.min_width.value() += horiz_frame_padding;
if (wm_relevant_mods.min_height.is_set())
wm_relevant_mods.min_height.value() += vert_frame_padding;

@AlanGriffiths
Copy link
Collaborator Author

Oh, ho! So this is so we execute these statements?

Yes, we needed to relax the condition on L232. After which we also fake any values that are not currently set. We already handle the client modifying things after that

Copy link
Contributor

@tarek-y-ismail tarek-y-ismail left a comment

Choose a reason for hiding this comment

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

Alright. Now makes sense. Would prefer if we handle cases like these explicitly but I'm sure the code would be more spaghettified with all the jank clients throw at us :)

@tarek-y-ismail tarek-y-ismail added this pull request to the merge queue Feb 26, 2025
Merged via the queue into main with commit 89c6204 Feb 26, 2025
37 of 40 checks passed
@tarek-y-ismail tarek-y-ismail deleted the unmapped-windows-also-adjust-decoration-borders branch February 26, 2025 16:52
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.

[SSD] Incorrectly sizes some windows
3 participants