Window is blurred in non fullwindow apps and on Xwayland apps

[rempas]

Please fill out the following:

• Scroll Version: scroll version 1.11.1

• Debug Log: scroll.log

• Configuration File: The error existed with the default configuration. However, here is my output settings in case it matters: output DP-1 resolution 2560x1440@179.959Hz scale 1.55 scale_filter nearest bg NotTheActualImageLmao.jpg fill

• Description:
  Text on windows that are not full screen is noticeably. When I make the app fullscreen, it works great (tho still maybe the most "crisp" text I've seen but you get my point). But when they are not full screen, it gets blurry. I don't know if it only affects text but this is where it's most noticable.

For comparison, this is the NON fullscreen (blurry):

And, this is the fullscreen (clear):

Now, don't worry... IT GETS WORSE! When it comes to Xwayland, the text (and it seems the icons) is straight BROKEN! Here is a screenshot of pixieditor:

And no, making Xwayland apps fullscreen does not fix the problem. Maybe sliiiightly. Improving it but, it doesn't fix it.

But wait! You thought we're over? No no no. There is another weird thing that happens. You see, when resizing a window, it momentarily becomes clear and when the animation is complete, it returns back to becoming blurry again. I slowed down the animations to notice this better and it is very clear! But, it's not just that. There are certain window sizes that make the content more clear than others. I noticed that and to be sure, I put my head super close to the screen to test and playing with resizing, it does happen (tho, this is the weakest effect out of all the other things I mentioned).

Finally, I have something else that might help. I noticed something. Hyprland does not let you use any scale you want. It does support specific ones like "1.33", "1.666667", etc. I don't know if there are sort of "safe" scales for each monitor and resolution but I do mention it because Hyprland has the clearest text I've ever seen! And it used to be based on wlroots (tho, I test the latest release which isn't, I don't know how it was before that) so, it might be something helpful. Tho, keep in mind, when scrolling in browser, text can sometimes appear distorted (like it's "cut") in the top or bottom sometimes. So, I don't know, text rendering is super weird...

In a funny note now, despite been blurry, no other compositor was able to scale pixieditor. So, good job on that 😅

[dawsers]

You are using version, 1.11.1, there have been changes after that one that may have (or may have not) improved rendering. Please, for bug reports, use the latest version, or if you want to stay in the stable branch, use the latest stable version, currently at 1.11.5.

For example, XWayland has received many updates lately. However, it is a know thing XWayland doesn't like scales different than 1, and you will always get blurrier text unless your scale is 1.0. scroll uses rootless XWayland, so the X applications integrate with the desktop instead of each one using a different server root instance (like when running xwayland-satellite). That has a problem, X applications will be scaled to the same scale that you set for your monitor, in your case 1.55 (a bit weird, I would think). Hyprland supports rendering those X applications buffers at 1.0 through a runtime option. scroll doesn't support that at the moment, because it would also require collaboration from the x server and wlroots.

I would also recommend you used the default filter instead of setting it to nearest. A normal scale instead of 1.55...for example 1.5 would also help, but maybe you need 1.55 instead of 1.5 for some reason, I am not to judge that.

I am currently working on several things that will make rendering better, but probably never as good as you may need.

Thank you for the issue report, I will keep looking into it.

EDIT: In case you are interested, fractional scales are represented by a fraction, so regardless of the value you set it to, it will be converted into a numerator for a fraction whose denominator is always 120. So your 1.55 will be 186, 1.5 would be 180 and so on. So not every number is valid.

[rempas]

You are using version, 1.11.1, there have been changes after that one that may have (or may have not) improved rendering. Please, for bug reports, use the latest version, or if you want to stay in the stable branch, use the latest stable version, currently at 1.11.5.

Oh, my god, I'm so so so so sorry!!! I didn't even notice that the AUR package is outdated. I will compile this the latest stable version (I feel like not going the current as, the project is in a good state already) later when I can and I will test. I checked the release logs and you mention lots of bug fixes so, some other tiny bugs I had might be fixed.

For example, XWayland has received many updates lately. However, it is a know thing XWayland doesn't like scales different than 1, and you will always get blurrier text unless your scale is 1.0. scroll uses rootless XWayland, so the X applications integrate with the desktop instead of each one using a different server root instance (like when running xwayland-satellite). That has a problem, X applications will be scaled to the same scale that you set for your monitor, in your case 1.55 (a bit weird, I would think). Hyprland supports rendering those X applications buffers at 1.0 through a runtime option. scroll doesn't support that at the moment, because it would also require collaboration from the x server and wlroots.

Oooooh, I see! It does make sense now. Both Niri (xwayalan-satellite) and Hyprland ("normal" xwayland) had the behavior so I wondered how you did it, lol! Why is my scale weird, btw? 😆

I would also recommend you used the default filter instead of setting it to nearest. A normal scale instead of 1.55...for example 1.5 would also help, but maybe you need 1.55 instead of 1.5 for some reason, I am not to judge that.

Thanks! I tested both of them and they seem to behave the same. I will remove it. I will also make sure to diff the current default config with the new on in 1.11.5 to make sure I don't miss/break something.

I am currently working on several things that will make rendering better, but probably never as good as you may need.

Fullscreen rendering is pretty good. Again, it's not as good as hyprland but, it doesn't need to. As long as it isn't noticeably blurry, I will be very happy.

Thank you for the issue report, I will keep looking into it.

The pleasure is all mine! Anything I can do to contribute to this amazing project! If you want to know, I did a bug report on Niri on Sunday and I had to change compositors to see if it's a problem on my side or Niri's side. I first went to hyprland and tried to use their scrolling plugin but, it didn't have lots of features and after the boot, straight up didn't work. Then, I did found about your plugin which was abandoned so you make scroll and I did try scroll, and it's amazing!!! Everything works great and I'm so, so happy! Yes there are some more features and suggestions I could make but first of all, bugs are the most important so, I want to take my time using and learning about it (I just learned about Lua scripting today for example) and then go with the suggestions. I will compile the latest stable version and I will update!

EDIT: In case you are interested, fractional scales are represented by a fraction, so regardless of the value you set it to, it will be converted into a numerator for a fraction whose denominator is always 120. So your 1.55 will be 186, 1.5 would be 180 and so on. So not every number is valid.

Wait! Then... Wouldn't it be a great idea to act like hyprland and throw an error to the config when someone tries to set invalid numbers? If anything, I think that this is the right behavior is, we protect the user. But of course, that's just a suggestion, it's up to you to decide.

[dawsers]

I am sorry, if you are using the AUR package sway-scroll-stable, that is not outdated. I saw version 1.11.1 in the log, and thought you were using an older version, but it may be the package is not setting the correct version on the logs. So you are on the latest stable version, and for now that should be almost as good as it gets, except for a few bugs.

A monitor scale of 1.55 is weird in my opinion because it doesn't help rendering or text crispness, and doesn't provide any benefit that I may understand. Using 1.5 would make rendering much better, easier, and in terms of functionality it is almost the same as 1.55. Maybe Hyprland decided for you to use 1.5 and that is what you are using there without knowing it.

I don't really want to limit the user or handhold them, unless their decision may produce a crash or be terribly wrong. So, for example, if someone wants to use a scale of 1.55, they may have a reason I am not aware of. But I can recommend changing it to 1.5, as I am doing here. You text rendering will be better.

There will be improvements coming shortly, but I would recommend you set the scale to 1.5 in the meantime and see if that helps you.

Thank you again.

[rempas]

I am sorry, if you are using the AUR package sway-scroll-stable, that is not outdated. I saw version 1.11.1 in the log, and thought you were using an older version, but it may be the package is not setting the correct version on the logs. So you are on the latest stable version, and for now that should be almost as good as it gets, except for a few bugs.

Huh? Well, now that I checked it again, I remember checking it and seeing it's the latest version. Now, I understand why I felt so weird before. I did check the pkgbuild (in case you had made a mistake, I see you're the maintainer) and it indeed seems to properly have the version. However, how is it possible that the wrong version will be reported by "scroll" just for the aur package? It doesn't make sense...

Also, regarding the version, should I do bug reports for some other things I found if I don't use the git version? Of course if you want me, I can change to the git version and always use that, I don't really care so much.

A monitor scale of 1.55 is weird in my opinion because it doesn't help rendering or text crispness, and doesn't provide any benefit that I may understand. Using 1.5 would make rendering much better, easier, and in terms of functionality it is almost the same as 1.55.

1.5 is smaaaaaaaaaall! 😭

Nah, I'm kidding. It's not a big difference. I even had 1.45 in Niri up to a few days ago. I'll be fine.

Maybe Hyprland decided for you to use 1.5 and that is what you are using there without knowing it.

Actually, hyprland lets me use either 1.33 or 1.666667 (I think it was 5 or 6 "6"). Nothing in between. I think at least. I might be forgetting something...

You know what, let me go to compare it with both "1.5" and "1.55" with Niri to see how it does out of curiosity.

I don't really want to limit the user or handhold them, unless their decision may produce a crash or be terribly wrong. So, for example, if someone wants to use a scale of 1.55, they may have a reason I am not aware of. But I can recommend changing it to 1.5, as I am doing here. You text rendering will be better.

I like this. But the thing is, what if the user doesn't know that? Should we at least have a NOTE in the config file or at least in the man pages to let the users know to optionally use some specific values in case their text looks bad? I'm saying this because, ok, I did made that issues. But not everyone will. In fact, most people will say "oh, it looks bad, I'm out" because they might not imagine that something is happening or that they did something wrong. So, I think something as simple as a note would be nice :)

There will be improvements coming shortly, but I would recommend you set the scale to 1.5 in the meantime and see if that helps you.

Already done! I think things are not as blurry now (in fact, there is very little blur) and there doesn't seem to be the difference between the windows (tho, more testing is needed to say be 100%, but I can't do it right now, so, I'm just mentioning it)

Thank you again.

Thank you too! I was so happily surprised with Scroll! I will not have to make my own compositor after all! I am planning to make a post in the discussion page to say about my thoughts and ideas soon. For now, thank you so, so much for caring so much and for doing such an amazing work! Let me tell you that I also love the Lua integration and how we can use a fully fledged programming language to configure scroll to our liking! I also especially love it because you stated that the reason you move from hyprland is because their API started limiting you on what you could do with hyprscroller, so I'm sure you want to make the API of scroll as extensible as possible.

If I could ask one thing here, as we talk, how does rendering differ between compositors? I heard that in Wayland, windows do the rendering themselves so, what role the compositor plays in rendering and how it matters so much? I'm asking because I care to learn both as general knowledge and hopefully, be able to help you improve the code of rendering (and not only) at some point in the future.

[dawsers]

The version reported by scroll may be wrong, I will have a look at it. There is an automated thing to take care of that, but maybe it isn't working well.

Also, regarding the version, should I do bug reports for some other things I found if I don't use the git version? Of course if you want me, I can change to the git version and always use that, I don't really care so much.

You can report bugs in the git or the latest stable version, both will be looked into. Some bugs may have been fixed in the git version before a new stable version happens. I usually wait a few weeks. So if you want to be on the cutting edge, or you think you will be filing many issues, the best way to verify the fixes work is to use the git version, because I will not backpatch immediately to the stable version, like I mentioned above.

Actually, hyprland lets me use either 1.33 or 1.666667 (I think it was 5 or 6 "6"). Nothing in between. I think at least. I might be forgetting something...

You know what, let me go to compare it with both "1.5" and "1.55" with Niri to see how it does out of curiosity.

I don't know what those other compositors do with respect to fractional scaling. When I was using Hyprland, and now in scroll I use 1.25. As I told you in a previous comment, fractional scaling is a fraction with denominator 120. So 1.5, for example is 180/120. 180 is a multiple of 2, 3, and 5, so it is a good fraction to favor scaling. 186 (1.55) is not a multiplier of 5 instead, so it is inferior.

I like this. But the thing is, what if the user doesn't know that? Should we at least have a NOTE in the config file or at least in the man pages to let the users know to optionally use some specific values in case their text looks bad? I'm saying this because, ok, I did made that issues. But not everyone will. In fact, most people will say "oh, it looks bad, I'm out" because they might not imagine that something is happening or that they did something wrong. So, I think something as simple as a note would be nice :)

OK, good point.

I think things are not as blurry now (in fact, there is very little blur) and there doesn't seem to be the difference between the windows (tho, more testing is needed to say be 100%, but I can't do it right now, so, I'm just mentioning it)

I am glad it is working better.

Thank you too! I was so happily surprised with Scroll! I will not have to make my own compositor after all! I am planning to make a post in the discussion page to say about my thoughts and ideas soon.

Please do, suggestions are always welcome.

If I could ask one thing here, as we talk, how does rendering differ between compositors? I heard that in Wayland, windows do the rendering themselves so, what role the compositor plays in rendering and how it matters so much?

Rendering is done by the applications, the compositor only displays those textures. However, there is scaling that needs to be applied. For example, monitor fractional scaling, or in the case of scroll, all the workspace and content scaling that it supports. Other compositors don't support hat complexity (workspace and content scaling), so it is easier to always get the correct viewport for each texture. That is what I am working on right now, hoping to improve.

[rempas]

You can report bugs in the git or the latest stable version, both will be looked into. Some bugs may have been fixed in the git version before a new stable version happens. I usually wait a few weeks. So if you want to be on the cutting edge, or you think you will be filing many issues, the best way to verify the fixes work is to use the git version, because I will not backpatch immediately to the stable version, like I mentioned above.

Hm.... Given the fact that I want to report bugs in general, so I make your life as easy as possible, I will switch in the git version! At least until I cannot find any more bugs and until you also consider Scroll to be practically "perfect".

I am glad it is working better.

Thanks. It's weird tho. There is surely some bug or the way the algorithm is implemented. Blurriness seems to come on and off as there are other windows around and as sizing changes. As crazy as it sounds, sometimes, I also feel like the text gets a bit blurrier and then comes back to how it was as a type in text like right now. I don't know if it's placebo...

You sure you didn't break something from Sway? Hmm.... You know what? Let me check sway tomorrow! Based on what you say below, you seem to change the rendering code so maybe you introduced a bug. I'll check sway tomorrow with both scaling "1.5" and "1.55" and tell you the result! If it has the same behavior than it surely something taken from it or, something that wlroots does.

Btw, speaking about wlroots, wouldn't it be possible to get away from it like hyprland did? You stay purely to not do that work, or there are other reasons?

Please do, suggestions are always welcome.

Alight! I'm glad you enjoy it. Thank you so so much! I will also create scripts and share them with the community. You could also have a look at them and see if you like to implement something of that to be built-in (or maybe tell me if it already exist and I'm an idiot wasting my time creating a script, lol). At some point, I also want to contribute to CachyOS and make a configuration for Scroll as they have so many compositors/wm/de that they offer in their ISOs. But of course, this will take lots of time.

Rendering is done by the applications, the compositor only displays those textures. However, there is scaling that needs to be applied. For example, monitor fractional scaling, or in the case of scroll, all the workspace and content scaling that it supports. Other compositors don't support hat complexity (workspace and content scaling), so it is easier to always get the correct viewport for each texture. That is what I am working on right now, hoping to improve.

I see... So scaling is the root of the evil. In that case, I understand what you try to do is complex but the good thing when something is not perfect is that, there is room for improvement and when we see the result of our hard work, it always excites us. That's how I see it of course and it does help me a lot!

[dawsers]

There are no plans to move from wlroots. There are not even plans to move away from sway. sway and wlroots provide a lot of features and stability, protocol implementations etc. I try to change as few things as possible while providing the features I need. There are already a lot of things to do without even thinking of writing a full compositor from scratch. This is a small project with a few dozen users and basically one developer. Let's move one step at a time.

[rempas]

There are no plans to move from wlroots. There are not even plans to move away from sway. sway and wlroots provide a lot of features and stability, protocol implementations etc. I try to change as few things as possible while providing the features I need. There are already a lot of things to do without even thinking of writing a full compositor from scratch. This is a small project with a few dozen users and basically one developer. Let's move one step at a time.

I love that mindset. If you think wlroots and sway don't limit you in any way, then it indeed makes sense to stay on them. They are tested platforms, after all. I will try to write some code myself soon. I might just need some help to understand a few things (including links for resources) if you don't mind.

[dawsers]

If you want to write some Lua scripts, there is an open discussion with examples and comments from people. Feel free to ask questions there or post some code for comments or reference.

For now, that discussion and man 5 scroll are the best sources of information. The manual is up to date and contains all the details of each command and Lua API.

[rempas]

If you want to write some Lua scripts, there is an open discussion with examples and comments from people. Feel free to ask questions there or post some code for comments or reference.

For now, that discussion and man 5 scroll are the best sources of information. The manual is up to date and contains all the details of each command and Lua API.

Thanks! I already saw that thread and used your maximization script! It's awesome and just what I needed. Tho, it's a bit buggy sometimes and the closing animations is a bit weird. I do have lots to learn tho so, it's surely exciting! I also looked at man 5 scroll and there seems to be TONS of stuff! I think I won't even have to write lots of scripts to begin with! I also love the way keybindings work on scroll/sway/i3! I love how you can execute multiple ones.

[dawsers]

There is the toggle_size command that does that. I implemented it after writing the script. You probably want toggle_size this 1.0 1.0. In the default config it is assigned to $mod+t:

# Toggle Size (and maximize)
bindsym $mod+t toggle_size this 1.0 1.0
bindsym $mod+Shift+t toggle_size active 1.0 1.0

mode "togglesizeh" {
    bindsym 1 toggle_size all 0.125 1.0; mode default
    bindsym 2 toggle_size all 0.1666666667 1.0; mode default
    bindsym 3 toggle_size all 0.25 1.0; mode default
    bindsym 4 toggle_size all 0.333333333 1.0; mode default
    bindsym 5 toggle_size all 0.375 1.0; mode default
    bindsym 6 toggle_size all 0.5 1.0; mode default
    bindsym 7 toggle_size all 0.625 1.0; mode default
    bindsym 8 toggle_size all 0.6666666667 1.0; mode default
    bindsym 9 toggle_size all 0.75 1.0; mode default
    bindsym 0 toggle_size all 0.833333333 1.0; mode default
    bindsym minus toggle_size all 0.875 1.0; mode default
    bindsym equal toggle_size all 1.0 1.0; mode default
    bindsym r toggle_size reset; mode default

    # Return to default mode
    bindsym Escape mode "default"
}
bindsym $mod+Ctrl+t mode "togglesizeh"

mode "togglesizev" {
    bindsym 1 toggle_size all 1.0 0.125; mode default
    bindsym 2 toggle_size all 1.0 0.1666666667; mode default
    bindsym 3 toggle_size all 1.0 0.25; mode default
    bindsym 4 toggle_size all 1.0 0.333333333; mode default
    bindsym 5 toggle_size all 1.0 0.375; mode default
    bindsym 6 toggle_size all 1.0 0.5; mode default
    bindsym 7 toggle_size all 1.0 0.625; mode default
    bindsym 8 toggle_size all 1.0 0.6666666667; mode default
    bindsym 9 toggle_size all 1.0 0.75; mode default
    bindsym 0 toggle_size all 1.0 0.833333333; mode default
    bindsym minus toggle_size all 1.0 0.875; mode default
    bindsym equal toggle_size all 1.0 1.0; mode default
    bindsym r toggle_size reset; mode default

    # Return to default mode
    bindsym Escape mode "default"
}
bindsym $mod+Ctrl+Shift+t mode "togglesizev"

[rempas]

There is the toggle_size command that does that. I implemented it after writing the script. You probably want toggle_size this 1.0 1.0. In the default config it is assigned to $mod+t:

# Toggle Size (and maximize)
bindsym $mod+t toggle_size this 1.0 1.0
bindsym $mod+Shift+t toggle_size active 1.0 1.0

mode "togglesizeh" {
    bindsym 1 toggle_size all 0.125 1.0; mode default
    bindsym 2 toggle_size all 0.1666666667 1.0; mode default
    bindsym 3 toggle_size all 0.25 1.0; mode default
    bindsym 4 toggle_size all 0.333333333 1.0; mode default
    bindsym 5 toggle_size all 0.375 1.0; mode default
    bindsym 6 toggle_size all 0.5 1.0; mode default
    bindsym 7 toggle_size all 0.625 1.0; mode default
    bindsym 8 toggle_size all 0.6666666667 1.0; mode default
    bindsym 9 toggle_size all 0.75 1.0; mode default
    bindsym 0 toggle_size all 0.833333333 1.0; mode default
    bindsym minus toggle_size all 0.875 1.0; mode default
    bindsym equal toggle_size all 1.0 1.0; mode default
    bindsym r toggle_size reset; mode default

    # Return to default mode
    bindsym Escape mode "default"
}
bindsym $mod+Ctrl+t mode "togglesizeh"

mode "togglesizev" {
    bindsym 1 toggle_size all 1.0 0.125; mode default
    bindsym 2 toggle_size all 1.0 0.1666666667; mode default
    bindsym 3 toggle_size all 1.0 0.25; mode default
    bindsym 4 toggle_size all 1.0 0.333333333; mode default
    bindsym 5 toggle_size all 1.0 0.375; mode default
    bindsym 6 toggle_size all 1.0 0.5; mode default
    bindsym 7 toggle_size all 1.0 0.625; mode default
    bindsym 8 toggle_size all 1.0 0.6666666667; mode default
    bindsym 9 toggle_size all 1.0 0.75; mode default
    bindsym 0 toggle_size all 1.0 0.833333333; mode default
    bindsym minus toggle_size all 1.0 0.875; mode default
    bindsym equal toggle_size all 1.0 1.0; mode default
    bindsym r toggle_size reset; mode default

    # Return to default mode
    bindsym Escape mode "default"
}
bindsym $mod+Ctrl+Shift+t mode "togglesizev"

Ok, I will probably not need scripting at all, lol! And you know what's funny? The more you implemented, the more easy it will be to do the few things that are so extreme and special. But I'm changing my config as we speak (even tho I should be sleeping but who cares about sleep, right?) and I find solutions for so many things. I'll sure make the cachyos config and let people know how awesome scroll is! Seriously, thank you so so much!

[rempas]

Alight, good morning (if it's day for you), I hope you have a good day! I did try sway, and it does have a similar behavior yet, in there the content (it's not just text) gets blurrier after the window shrinks to a certain size. I'm also very sure that fullscreen the window and having it non-fullscreen doesn't do a difference there (of course, that's for non-full windows that are above that mentioned size that makes theme blurrier). I did open an issue if you are curious to see. Thank you both for your amazing work!

Now, until you reply, let me go mess with those keybindings 😅