Buffer size is not divisible by scale - One more time...

[mindrunner]

Please fill out the following:

• Sway Version:
  sway version 1.8

• Debug Log:
  Will provide if needed

• Description:
  Well known issue already:
  Apps crash if sway output scaling is not equal to 1 #6014
  imv and mpv broke with latest sway #7050

It seems to need fixes in every single client. I see this happening in my chromium when I drag an image from a website. (crashes chromium with the following log):

❯ chromium 
[533418:533464:0124/134622.581866:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.portal.FileChooser”
[533418:533464:0124/134622.581937:ERROR:select_file_dialog_linux_portal.cc(274)] Failed to read portal version property
[533476:533476:0124/134624.344844:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is egl, ANGLE is 
[533418:533418:0124/134629.629733:ERROR:wayland_event_watcher.cc(38)] libwayland: wl_surface@43: error 2: Buffer size (281x80) is not divisible by scale (2)

[0124/134629.643027:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0124/134629.643789:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Trace/breakpoint trap (core dumped)

Is this image drag'n'drop from browser windows implementation in sway or in browser itself? Do I need to report this to chromium devs rather?

[emersion]

Yes, this is a Chromium bug.

[mindrunner]

I'd be very interested in insight why this is implemented in a 'wrong' way in so many applications? Especially because wlroots code already had a workaround/fix for that. From a user's perspective, the change of removing this workaround was a very bad idea. I understand the intention of doing so, if that really needs to be implemented in every client, but maybe the timing was not the best one then? Can you please provide more information why exactly size needs to be divisible by scale and what makes it so bad to have this additional line of code preventing clients to crash that all users need to suffer. :(

[mindrunner]

Bug reported upstream:
https://bugs.chromium.org/p/chromium/issues/detail?id=1409940

Thanks for sway! Awesome piece of software, despite some frustration sometimes :)

[emersion]

I'd be very interested in insight why this is implemented in a 'wrong' way in so many applications?

Multiple reasons:

• Sometimes apps want to use a fixed size image as surface contents. They will use images with odd dimensions even if that is non-sensical for a 2× scale.
• Some clients send buggy surface commits: for instance, they set their scale in one commit and actually update their buffer in a separate commit.

From a user's perspective, the change of removing this workaround was a very bad idea

It is not removing a workaround. It is making sure clients comply with the spec to avoid glitchy frames.

Bug reported upstream

Thanks!

[talex5]

Just hit this myself after upgrading to NixOS 23.05. I use a proxy for X11 applications, and they are obviously unaware of Wayland's requirements about window sizes.

I tried rounding the window sizes down, but that has a bad side-effect: if GTK asks for a 1001-pixel high menu and gets a 1000 pixel allocation, it switches to squashed mode and draws two big bumper arrows at the top and bottom of the menu which you must use to scroll it!

I also tried rounding up, but tooltips look bad with any rounding. Either one border is missing, or it's double thickness.

It seems that Sway is perfectly capable of handling odd-number sizes, since it used to work. Is there any way to get the old behaviour back? What is the recommended way to deal with this?