Fractional scale support about swww HOT 12 CLOSED

Might be a good oportunity to implement wl_surface.preferred_buffer_scale, where the compositor explicitly informs of the desired scale.

from swww.

Would this also help with #40?

from swww.

Probably. I'm pretty sure fractional scaling is messing up those values.

from swww.

Is this lack of support the reason why the grow animation is laggy on a scaled monitor? 🤔

from swww.

Is this lack of support the reason why the grow animation is laggy on a scaled monitor? 🤔

I think that's unlikely. You could test it by setting the scale factor to a whole number and seeing if it still lags.

from swww.

I don't have any visible lag when using non-scaled 4k monitor.

However I stumbled upon #108 and manage to workaround that. Doing so, I've found something weird in the logs: the same monitor (the scaled one) shows up twice:

Here is with scaling factor of 1:

❯ swww init --no-daemon
08:36:03 [INFO] (main) Initialization succeeded! Starting main loop...
08:36:03 [INFO] (main) failed to find cached image for monitor 'eDP-1'
08:36:03 [INFO] (main) failed to find cached image for monitor 'DP-4'
08:36:03 [INFO] (main) failed to find cached image for monitor 'DP-7'

That's with scaling factor of 1.5:

❯ swww init --no-daemon
08:37:50 [INFO] (main) Initialization succeeded! Starting main loop...
08:37:50 [INFO] (main) failed to find cached image for monitor 'eDP-1'
08:37:50 [INFO] (main) failed to find cached image for monitor 'DP-4'
08:37:50 [INFO] (main) failed to find cached image for monitor 'DP-7'
08:37:50 [INFO] (main) failed to find cached image for monitor 'DP-7'

Probably the reason why the animation seems laggy: there may actually be 2 overlapping animations 🤔

Both hyprctl and wlr-randr report 3 monitors, not sure where the confusion from swww comes from.

Here is swww with surprising scale and resolution (resolution is after scaling 1.5, maybe scale is rounded?) but correct monitor count:

❯ swww query
eDP-1: 1920x1200, scale: 1, currently displaying: image: "fence.jpg"
DP-4: 1920x1200, scale: 1, currently displaying: image: "fence.jpg"
DP-7: 2560x1440, scale: 2, currently displaying: image: "fence.jpg"

And here wlr-randr:

❯ wlr-randr
DP-7 "Dell Inc. DELL S2722QC (DP-7)"
  Make: Dell Inc.
  Model: DELL S2722QC
  Modes:
    3840x2160 px, 60.000000 Hz (preferred, current)
  Position: 1920,0
  Transform: normal
  Scale: 1.500000
DP-4 "Ancor Communications Inc PA248 (DP-4 via HDMI)"
  Make: Ancor Communications Inc
  Model: PA248
  Modes:
    1920x1200 px, 59.950001 Hz (preferred, current)
  Position: 4480,120
  Transform: normal
  Scale: 1.000000
eDP-1 "Sharp Corporation 0x14F9 (eDP-1)"
  Make: Sharp Corporation
  Model: 0x14F9
  Modes:
    1920x1200 px, 59.950001 Hz (preferred, current)
  Position: 0,120
  Transform: normal
  Scale: 1.000000

Not sure if this is expected, if I should open another bug report or if it's linked to this one 😬 Please let me know 👍

from swww.

@Diaoul, sorry for not responding for so long.

The latest master has changed a lot (including a full rewrite of the wayland code), so I'd have to ask you to retest those findings. If the issues remain, you should open a new issue so we can track them better.

from swww.

No worries, I'll test again in the coming days and report back!

from swww.

Anything new? for me gif wallpaper and transitions are laggy with scaling but perfect without. Nixos, hyprland

from swww.

For shotman, I used an Enum to save the current scale:

https://git.sr.ht/~whynothugo/shotman/tree/09a5219028a0f37e86fc592efa43865a684e9ddd/item/src/main.rs#L255-265

Each of these values comes from a different source (which may or may not be available depending on the compositor's protocol support). When the compositor informs of a new scale, I only save it if it is a variant that is defined below the current one. It's somewhat messy, but cover all scenarios.

I wish I knew how to make proper reusable code; most of the logic is too intertwined with the rest of shotman.

from swww.

This is probably next on the list. Took a while, but we'll get there 😓

from swww.

@WhyNotHugo your code was actually very helpful. It would have taken me a lot longer without using it as a basic reference. Thanks!

from swww.