Wrong initial window size on unfocused monitor

[Kam1k4dze]

#9057
Dwindle window size prediction assumes that new windows always spawn at the current window focus, which isn’t true

[vaxerski]

minor issue, and I am not sure if we can even reliably detect where a window will end up at that stage

[Kam1k4dze]

Idk how minor it is, with animations=0 it's very noticeable, especially on low-end hardware. After I upgraded to a 9950X I can't really see the bug when animations are enabled, but with animations disabled it's still obvious, and not everyone has a 9950X
Like, I saw someone use Hyprland for five minutes with animations off and ask why window content briefly stretches even though they disabled animations

[sand4rt]

i had the same request: #11509

Its really annoying without animations..

[tekstryder]

This issue is the reason I've no wallpaper, just solid black, as it visually exacerbates the "glitchy" pseudo-animation.

I don't see the same behavior with Sway.

[Kam1k4dze]

@vaxerski I think many people disagree with the statement that this is a minor issue.

[Kam1k4dze]

Speaking of dumb stuff: #9116 it made this less visible.
Is it really impossible to predict the size at this stage (I didn't look at this deeply because I felt it was too much work to do), and why do we need size prediction in the first place?

[sand4rt]

whats the usecase for good looking windows?

Not getting flashbanged every time I open one: #11509 :( This matters especially for apps where the content depends on window dimensions—like mpv or swayimg—where a jarring visual is really distracting.

jkjk but there aint much I can do really without nuking size prediction or doing something dumb :/

That's unfortunate—some folks are saying this isn’t an issue in Sway though: #11466 (reply in thread). I wondered if there is something that could be learned from their approach?

[vaxerski]

maybe they don't render the first frame at all?

I mean we could do this dumb thing I guess, please try:
patch.txt

[gulafaran]

maybe they don't render the first frame at all?

I mean we could do this dumb thing I guess, please try: patch.txt

wont that go out of size if one resolution is smaller then the other

[vaxerski]

yes, but my thought is clipping the surface will look less noticeable

[tekstryder]

I mean we could do this dumb thing I guess, please try: patch.txt

Thanks. I applied the patch atop v0.50.1 tag.

patching file src/events/Windows.cpp
Hunk #1 succeeded at 858 with fuzz 1 (offset -1 lines).

Hyprland 0.50.1 built from branch makepkg at commit 4e242d086e20b32951fdc0ebcbfb4d41b5be8dcc dirty ([gha] Nix: update inputs).
Date: Sat Jul 19 17:37:06 2025
Tag: v0.50.1, commits: 6291
built against:
 aquamarine 0.9.3
 hyprlang 0.6.3
 hyprutils 0.8.3
 hyprcursor 0.1.13
 hyprgraphics 0.1.5


flags set:
no xwayland

With animations disabled I don't see any glitchy behavior opening new windows. This matches Sway behavior.

Occasionally the background image will flash briefly in the area where a tile was when closing some windows. It would be cool if the tile that will fill that void could be drawn faster without that occurring.

The brief flash of background image when opening and closing windows is somewhat expected with animations enabled.

[tekstryder]

wont that go out of size if one resolution is smaller then the other

With the patch I've got some app dialog windows now extending beyond the viewable screen.

[vaxerski]

is this reproducible?

[tekstryder]

Looks like they are being created at some maximum size, ignoring the app-designated size, which is obeyed without the patch and without any window rules.

Examples include Nautilus "Properties" dialog and the "Preferences" window in ptyxis terminal:

Window 562eab209240 -> Preferences:
	mapped: 1
	hidden: 0
	at: -125,30
	size: 2880,2400
	workspace: 1 (1)
	floating: 1
	pseudo: 0
	monitor: 1
	class: org.gnome.Ptyxis
	title: Preferences
	initialClass: org.gnome.Ptyxis
	initialTitle: Preferences
	pid: 63512
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags: 
	swallowing: 0
	focusHistoryID: 2
	inhibitingIdle: 0
	xdgTag: 
	xdgDescription: 

Window 562ea8a91d70 -> tekstryder@boomshanka:~:
	mapped: 1
	hidden: 0
	at: 2881,-425
	size: 1350,2400
	workspace: 2 (2)
	floating: 0
	pseudo: 0
	monitor: 0
	class: org.gnome.Ptyxis
	title: tekstryder@boomshanka:~
	initialClass: org.gnome.Ptyxis
	initialTitle: Terminal
	pid: 63512
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags: 
	swallowing: 0
	focusHistoryID: 0
	inhibitingIdle: 0
	xdgTag: 
	xdgDescription:

monitor = DP-1, 3840x2160, 0x0, 1.333333
monitor = DVI-D-1, 2560x1440, 2881x-425, 1.066667, transform, 3

EDIT: In every case, such windows are always of 2880 x 2400 dimensions, regardless of which display.

[vaxerski]

right. I don't think this is actually solvable in a clean way. I know it's annoying, but feel free to suggest a way to fix this, as:

• not drawing the first frame: what if the window doesn't commit a new frame?
• predicting size for other monitor: what if window doesn't set a class / title at that stage yet?
• suggesting a larger size: above

[tekstryder]

Hey, thanks for the rationale and a quick patch to test.

I needed to rebuild hyprland for new Aquamarine and Hyprutils tags, so I took the opportunity to pop back into Sway, where I have a colorful background image, just to make sure what I said upthread is still true.

Yup, background never "peeks" through when opening or closing any number of windows on either display. There's simply no jankiness to either operation. I wonder what Sway does differently than Hyprland (with animations disabled).

I know it's annoying

Regardless, not that annoying. I re-removed my background image and re-enabled animations, cuz they are nice.

EDIT:
Could this come down to fundamental vulkan vs gles2 diffs?
There's jank galore when I run Sway on wlroots built with only the old gles2 renderer.

[vaxerski]

no it's not really vk vs gles that doesnt matter, it's more like "logic". We can't determine if a window is going to be floating until it maps, and we have to "suggest" a size for it before it maps.

[Kam1k4dze]

@vaxerski can you please promote this to an issue? It clearly is one, even if it can't be fixed right now.

[vaxerski]

even if it can't be fixed right now.

that disqualifies it from being an issue. A discussion is way better for discussing the solution. An issue is a ready-to-be-picked-up clear problem with a clear solution

[Kam1k4dze]

Understandable

[sand4rt]

@ddevault We really admire how you achieved zero flickering when opening and closing windows in Sway. Would you be willing to share some insights or advice on how you accomplished that?

Vaxerski considered a few (non-ideal) workarounds, but we have yet to identify a path forward:

• Not drawing the first frame: But what if the window doesn’t commit a new frame?
• Predicting the size for another monitor: What if the window hasn’t set its class or title yet at that point?
• Suggesting a larger size: As mentioned above, this has limitations.

* #11466 (reply in thread)

We’d appreciate any guidance or ideas—als je iets wilt delen, graag;)

[ddevault]

Sway has a system of layout transactions for this purpose. It waits for all implicated windows to acknowledge their new configuration, or for a timeout to expire. It looks like the timeout is 200ms.

I haven't worked on sway in years so you'll have to reach out to the current upstream stewards for more details. The core code is in sway/desktop/transaction.c, for reference.

[sand4rt]

Awesome! Thanks for the pointers. @vaxerski what do you think?: https://github.com/swaywm/sway/blob/master/sway/desktop/transaction.c

[vaxerski]

Niri also does transactions and personally I really hate them. They can cause the compositor to feel really sluggish especially on underpowered devices.

Imagine a manual mouse resize (mod + right click drag) with an app that is more-or-less slow to resize, and your 60/144/240hz display turns into 5Hz.

I've actively avoided adding transactions and instead would do everything I can to smooth out the inevitable desync in other ways. Sway has very few of these animations / resizes / etc, as it's a very keyboard-centric environment, where I rarely see people even using the mouse. In Hyprland, hell, I use the mouse all the time, and I'm far from the only one.

[vaxerski]

I doubt it will do much but checking #11770 might be worth a shot as it improves uv calculations and surface sync overall

[tekstryder]

Finally got around to checking this out and wow it's great.

This is nearly in parity with Sway behavior now when Hyprland animations are disabled.

Just the briefest of background image flashes through occasionally.

You've presented a conundrum... have a shiny cool desktop background image OR enable those snazzy improved animations with a solid black background. Decisions, decisions.

Thanks!