Not sure if that's some monitor size reporting bug or so?
It's not, I'll try rephrasing the issue here: the window size in this case is 2150x843. This display has a scale of 2. So the surface area should have been either 2150x843 (with scale=1) or 4300x1686 (with scale=2).
It could also be larger (e.g. 6450x2529 with scale=3) and the compositor would downscale it. That's kinda wasteful, but valid.
For reference, from wl_surface::set_buffer_scale:
Note that if the scale is larger than 1, then you have to attach a buffer that is larger (by a factor of scale in each dimension) than the desired surface size.
So, given that Firefox is calling set_buffer_scale with value 2, the buffer should be 4300x1686, and not 6450x2529.
My other monitor (which was not the window on which Firefox was rendering) has a scale of 3, and it seems that Firefox is using that value.
If you multiply 2150x843 by 3, you get 6450x2529. Firefox is scaling surfaces up by X, where X=3 is the largest scale of all available displays, but it is reporting that it has scaled up the surfaces by a scale equal to the output's scale (in this case, 2). These values are inconsistent. Firefox is sending a surface of 6450x2529 with scale=2. So this surface scales to 3225x1264.5px, a non-integer size. This is a protocol violation for a reason, and swaywm just crashes when receiving invalid input. Mutter seems to be more lenient and work around it (there's likely some visual artefact though, since the numbers simply don't add up).
This results in two big problems:
- As mentioned above, it renders something gigantic which the compositor then has to downscale. This is problematic but non-fatal.
- The main topic at hand in this issue: Firefox says "here's a 6450x2529 surface which is scale 2x", but 2529 is CLEARLY not divisible by 2. The input is invalid, and swaywm rejects this invalid input.
This bug is fatal. IF the window has a size Y such that Y/3 is integer but Y/2 is not, Firefox crashes immediately (in this case, 3 and 2 are the scales of each of my displays). It is an EXTREMELY annoying bug, because it means that I basically have to chose between running Firefox, or using two displays, but I cannot do both.
To summarise this in shorter terms:
- Firefox scales the buffer by 3x.
- Firefox tells the compositor that the buffer is scaled up by 2x.
- Firefox send the buffer data.
- The numbers don't make sense, and the compositor kills the client because the client is sending bogus data.
Anyway, looking forward to see updated mutter so we can fix that.
The fact that Mutter accepts this input is really non-standard behaviour. It's being lenient, ignoring the error, and doing something other than what the spec specifies (maybe it's just discarding a column of pixels? maybe it's overflowing somewhere?). The result should have visual artefacts, because the math just doesn't add up.
Why is Mutter's behaviour here a blocker for this issue?
Window size it not set by widget code, widget renders what Firefox/layout sends.
I don't quite understand this statement.