wayland hidpi support#854
Conversation
fwsmit
changed the title
|
@adamcstephens @bebehei The wayland HiDPI support is implemented! Could you test it? With an integer scaling factor everything should look razor sharp, and with a non-integer scaling factor it is rendered in the nearest scaling above that and scaled down from there. Everything should work pretty well. The only thing I've noticed is that some icons are smaller than when redered with a scale of 1, but that can probably be solved with min_icon_size. |
fwsmit
force-pushed
the
wayland-hidpi
branch
2 times, most recently
from
e2e1541 to
34ea6eb
Compare
This commit implements support for HiDPI rendering for wayland. X11 should be unaffected by this. It is implemented by scaling everything that's rendered by a scale factor that's obtained from the wayland protocol. All sizes before rendering remain the same, so the same settings should provide the same output for different scaling factors, only scaled by that factor.
|
The tests are now fixed. Icons are now also scaling properly, even when they're low resolution. The only bug remaining, which I probably won't fix is that the icons are not immediately updated on scaling. Only new notification have the bigger icons. |
|
I'm not seeing a difference with this patch. Let me know if there's any info I can provide to help, and I'm also on IRC. |
|
What compositor are you using? This is tested on sway. Debug output of Dunst would help as well |
|
I'm using sway 1.5.1 on Debian Bullseye. Here's the debug output: |
|
What scale are you using? A non-integer scale will not look perfectly sharp. Try a scale of 2 and see if it looks better with this PR than before |
|
@fwsmit Judging by mako's pango init, I suspect you need to set the pango scale attribute for better non-integer scaling of text. |
No unfortunately the wayland protocol only allows for integer scaling to be passed to an application (probably with good reason). The way sway allow for non-integer scaling is by passing the next integer above your scaling and scale it down afterwards. Most of the times it shouldn't matter, because you'll use it when you have a 4k screen which will work perfectly with 2x scaling. This is what it looks like on my pc (2x scale):
The text is definitely improved compared to before, but the icon might be worse, because it's blurry. I haven't looked into it yet, but I suspect the scaling method we use with gdk is different from the scaling method used by sway. Another notification (2x scale):
The line height seems to be slightly higher with this PR, so I'll look into if the pango scale function might help with that. Have you tried this PR by the way @paretje? |
|
Ah, sorry, it was the most obvious difference when I had a quick look at the codebases. I didn't notice scale was an int ... On my personal laptop, I have a 14'" QHD screen, and I apply a scaling factor of 1.25. Since I switched to sway, I have been using mako as my notification daemon, which works fine, but I'm missing some features. I knew dunst had Wayland support now, and wanted to try it. I ended up trying your PR, but I noticed the text to be very blurry. I don't have this issue with mako, which was why I ended having a look at the code. dunst: mako: |
|
Okay from your screenshot it looks like it can definitely be done better. I'll have to experiment a bit and maybe copy some code. Does a scaling factor of 2 not have any issues on your machine? |
|
Hmmm, yes, it doesn't really work with scaling factor 2 either for me.
|
|
Can you do a picture with the latest Dunst release as well? |
|
|
|
It seems like they are exactly the same. I think there must be something wrong in the scale detection then. I've added a debug print to see what scale you are using. Could you see if it even receives the right scale from the compositor? |
Codecov Report
@@ Coverage Diff @@
## master #854 +/- ##
==========================================
- Coverage 58.54% 58.09% -0.45%
==========================================
Files 37 37
Lines 5987 6040 +53
==========================================
+ Hits 3505 3509 +4
- Misses 2482 2531 +49
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
After zooming into those images I've found at least one difference that has nothing to do with the scaling. Mako apparently uses subpixel rendering for their fonts. Still, the 1.25x result from dunst doesn't look great. Below are zoomed in versions of you screenshots: Mako 1.25x Dunst 1.25x Dunst 2x |
|
Yes, I had noticed it and tried it, but it didn't really help. But, I now applied this additional diff: diff --git a/src/draw.c b/src/draw.c
index f3e3a6a..5df7298 100644
--- a/src/draw.c
+++ b/src/draw.c
@@ -142,6 +142,8 @@ static struct color layout_get_sepcolor(struct colored_layout *cl,
static void layout_setup_pango(PangoLayout *layout, int width)
{
int scale = output->get_scale();
+ LOG_D("Setup pango with scale %i", scale);
+
pango_layout_set_wrap(layout, PANGO_WRAP_WORD_CHAR);
pango_layout_set_width(layout, width * scale * PANGO_SCALE);
pango_layout_set_font_description(layout, pango_fdesc);
And now I get (using 1.25): So, while the output scale is updated to 2, which sounds right given it's an integer, when we actually setup pango, |
|
Oh, now I see why. int wl_get_scale(void) {
struct dunst_output *output = get_configured_output();
if (output)
return output->scale;
else
return 1;
} |
|
Thanks for debugging. The get_scale function may indeed return the default of 1 when it cannot detect what the current output is. This happens when |
|
It should use the right scale in any monitor configuration. It works fine to use a larger scale if the current output cannot be found. |
|
No, I don't use multiple monitors, it probably was just part of the default config at the time. When I sit at my desk, I use an external monitor, but my laptop monitor is disabled. dunst does crash when I switch between monitors though. I don't think (dis)connecting monitors is actually handled at the moment? The immediate cause is the fact that the initial value of scale is 0, so if for some reason there is no output, scale 0 is used, resulting in a division by zero in |
|
Okay thanks for mentioning. That will be an easy fix. Have you compared the text between Dunst and mako now? Is there still a lot of difference or only the subpixel rendering? |
|
No, dunst looks fine now, thank you. |
Cool! The divide by 0 issue is fixed as well. I'll see if I'll implement subpixel rendering as well. It should be only a few lines of code. |
|
I can confirm that this PR looks good now, and you've resolved the blurriness for me. It works for multiple monitors with different scales. Tested on:
|
Did you try it with |
I just tested both |
When there's only one output, just return that output.
When follow mode != none dunst cannot detect what output is being used to display the notification (yet). With this commit dunst falls back to using the largest scale from any ouput. The compositor should scale the buffer down again if the scale of the output is smaller that the used scale.
|
It sounds like you tested it pretty well. I don't see any issues either, except the icons not resizing immediately upon changing the scale. Subpixel font rendering will have to wait a bit as well, since it's not as easy as I thought. This PR is finished, though. We'll just have to wait for someone to merge it (might take a while, since the maintainers are busy). |
|
Sorry for the delay in merging this. I can't do much to test it as I'm not on wayland (yet) but I'll trust you saying it looks good. 👍 |
5 participants
Fixes #836
@bebehei This PR currently only implements scale detection on wayland. I'm making this PR already so you know I'm working on it.
To test it on sway, it's really easy:
swaymsg output "*" scale 1.5Sway will message a scale of 2 to dunst and it will scale it down to 1.5 afterwards.