[RFC] Wayland goodies about kitty

[neurocyte]

Gave it a quick test drive today. I don't usually use wayland but it seemed to work fine. The new window decorations are nice, although I miss the cat emoji a little.

The window contents flicker a bit during resize, which didn't happen with the previous build I was using (from last week or so). That was the only negative I noticed.

I tested on Gnome. I also have Hyprland, but I didn't have time to test that yet.

[kovidgoyal]

Yeah, I agree the cat emoji was fun, but more soberly, because its color was fixed, it could look out of place depending on overall desktop colors, which is why I removed it in favor of something that renders with the normal text foreground color.

As for flickering, I think that's caused by an extra window blanking before the redraw at the new size, I'll look into that when I have a moment.

[real-or-random]

Thanks for caring about Wayland!

Unfortunately, while #4802 (comment) has been resolved for me, I now noticed that fractional scaling support is, in fact, broken for me. If I set a fractional scaling factor in GNOME, kitty takes the ceil of it. I tried with multiple factors, e.g., when I set 125%, I'll get 200% in kitty. This has worked on the previous release, so it's a regression. This is on GNOME 46.0.

I had started seeing this on cd67184, but I also see it on the current master (1c3d3ad).

---

finally for the red headed stepchild

I seriously wonder what's wrong with red headed stepchildren.

[kovidgoyal]

On Wed, Apr 10, 2024 at 04:12:48PM -0700, Tim Ruffing wrote: Thanks for caring about Wayland! Unfortunately, while #4802 (comment) has been resolved for me, I now noticed that fractional scaling support is, in fact, broken for me. If I set a fractional scaling factor in GNOME, kitty takes the ceil of it. I tried with multiple factors, e.g., when I set 125%, I'll get 200% in kitty. This has worked on the previous release, so it's a regression. This is on GNOME 46.0.

How are you concluding you are getting 200% in kitty? There is no visible change, either kitty uses integer scale and mutter resizes or kitty uses fractional scale and mutter doesnt resize. You can run with --debug-rendering to verify kityt is creating buffers with fractional scale.

I had started seeing this on cd67184, but I also see it on the current master (1c3d3ad).

Seeing what?

--- > finally for the red headed stepchild I seriously wonder what's wrong with red headed stepchildren.

No idea :) Probably in ancient times red heads were considered fay/evil and stepchildren doubly so.

[real-or-random]

How are you concluding you are getting 200% in kitty?

I see it with my eyes. Okay, I didn't count the pixels, but I observe this:

• 0.33.1: Fractional scaling works: The rendered font size scales correctly for different settings, e.g., 125% is larger than 100%, 150% is larger than 125%, 200% is larger than 150%. (This had always worked for me.)
• 1c3d3ad: the rendered font size is the same, no matter if I set 125%, 150%, 175%, or 200%. It appears to be double the size of what I get when I set 100%, and it appears to be the size of 0.33.1 when set to 200%. I've verified that this happens even with -c=NONE.

These are logs with scaling set to 150%:
1c3d3ad:

[0,062] Compositor missing capabilities: layer_shell
[0,157] Creating window at size: 1002x640 and scale 1
[0,182] GL version string: '4.6 (Core Profile) Mesa 24.0.4-arch1.2' Detected version: 4.6
[0,193] Fractional scale requested: 180/120 = 1,50
[0,193] Resizing framebuffer to: 1503x960 window size: 1002x640 at scale: 1,50
[0,193] Preferred integer buffer scale changed to: 2
[0,193] Compositor set top-level bounds of: 1503x974
[0,193] Compositor top-level capabilities: maximize=1 minimize=1 window_menu=1 fullscreen=1
[0,193] XDG top-level configure event: size: 0x0 states: 
[0,193] XDG surface configure event received and acknowledged
[0,193] Final window content size: 1002x640 resized: 0
[0,193] Setting window "visible area" geometry in configure event: x=0 y=0 1002x640 viewport: 1002x640
[0,214] OS Window created
[0.228] Child launched
[0,229] Waiting for swap to commit: swap has happened, window surface committed
[0,308] Calling wl_pointer_set_cursor in setCursorImage with surface: 0x57e1d6fbf8b0 and serial: 0
[0,308] Compositor set top-level bounds of: 1503x974
[0,308] XDG top-level configure event: size: 1002x640 states: TOPLEVEL_STATE_ACTIVATED 
[0,308] XDG surface configure event received and acknowledged
[0,308] Final window content size: 1002x640 resized: 0
[0,308] Setting window "visible area" geometry in configure event: x=0 y=0 1002x640 viewport: 1002x640

0.33.1:

Creating window at size: 1002x640 and scale 2
GL version string: '4.6 (Core Profile) Mesa 24.0.4-arch1.2' Detected version: 4.6
top-level configure event: size: 0x0 states: 
final window content size: 1002x640 resized: 0
Setting window geometry in configure event: x=0 y=0 1002x640
Waiting for swap to commit: swap has happened
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x5f508cdd9ff0
top-level configure event: size: 1002x640 states: TOPLEVEL_STATE_ACTIVATED 
final window content size: 1002x640 resized: 0
Setting window geometry in configure event: x=0 y=0 1002x640
Scale changed to 2 in surface enter event
Resizing framebuffer to: 1002x640 at scale: 2

[kovidgoyal]

The font size is specified in points, a physical unit. It is supposed to
be the same regardless of scaling. So it is now working correctly.
Earlier it wasn't, and that's because the scale kitty was using was not
correct as the actual scaling was happening in the compositor.

Basically rendered font size in pixels is calculated from the specified
font size in points and the DPI of the screen. The DPI of the screen is
calculated on wayland as 96 * scale.

[real-or-random]

The font size is specified in points, a physical unit. It is supposed to
be the same regardless of scaling.

Okay. I'm pretty sure that this is contrary to what everyone expects from scaling. As I understand it, the world has mostly settled on this way of specifying sizes so that they work equally with normal screens and hidpi/retina screens:

There are physical pixels and virtual pixels. UI elements are specified in virtual pixels. The scaling specifies the ratio of their size, e.g., when the scaling factor is 1.5, that means that a window of 100x100 (virtual) pixels is rendered on the screen using 200x200 physical pixels. (That's why kitty needs to provide 200x200 pixels). However, again, users expect that sizes such as the font size are specified in virtual units, i.e., virtual pixels, or equivalently (with a factor of 0.75 assuming DPI 96), virtual points. This is how it's done, for example in Wayland and also on the web, see for example: https://news.ycombinator.com/item?id=29709309).

In other words: When I as a user change my scaling from 100% to 150%, I expect all UI elements to become 50% longer on my physical screen. This is what every other app does. For example, start gnome-terminal or your browser, change the factor from 100% to 150% and see how the physical font size changes in these applications. kitty should do the same.

It is supposed to
be the same regardless of scaling. So it is now working correctly.

Hm, even assuming your definition of "correctly" it's not. Now, 200% is twice as large as 100%. This is not "the same regardless of scaling".

[kovidgoyal]

On Thu, Apr 11, 2024 at 05:01:44AM -0700, Tim Ruffing wrote: > The font size is specified in points, a physical unit. It is supposed to > be the same regardless of scaling. Okay. I'm pretty sure that this is not what everyone expects from scaling. As I understand it, the world has mostly settled on this way of specifying sizes so that they work equally with normal screens and hidpi/retina screens: There are *physical* pixels and *virtual* pixels. UI elements are specified in virtual pixels. The scaling specifies the ratio of their size, e.g., when the scaling factor is 1.5, that means that a window of 100x100 (virtual) pixels is rendered on the screen using 200x200 physical pixels. (That's why kitty needs to provide 200x200 pixels). However, again, users expect that *sizes such as the font size are specified in virtual units*, i.e., virtual pixels, or equivalently (with a factor of 0.75 assuming DPI 96), virtual points. This is how it's done, for example in Wayland and also on the web, see for example: https://news.ycombinator.com/item?id=29709309). In other words: When I as a user change my scaling from 100% to 150%, I expect all UI elements to become 50% longer on my physical screen. This is what every other app does. For example, start gnome-terminal or your browser, change the factor from 100% to 150% and see how the physical font size changes in these applications. kitty should do the same. > It is supposed to > be the same regardless of scaling. So it is now working correctly. Hm, even assuming your definition of "correctly" it's not. Now, 200% is twice as large as 100%. This is not "the same regardless of scaling".

If that's the case then I dont follow what your initial problem is. Are you saying the rendered font size changes when you change between a scale of 2 and 3 but not 2 and 2.5?

[LawnGnome]

There is something weird going on here with fractional scaling and font sizes. I'll try to illustrate it with some screenshots below.

My setup: Sway 1.9, with output scale set to 1.5.

kitty 0.33.1 on the left; kitty master (as of about 10 minutes ago) on the right in all screenshots. They're loading the exact same configuration.

Initial run:

Obviously, the font size on the right is much bigger. But then if I hit Ctrl-Shift-F5 to reload the configuration in the master window:

Now the font size is much closer to the 0.33.1 window. (It's not exactly the same, as the echo $COLUMNS $LINES output in each window shows, but I have no idea if that's due to the recent Wayland changes or other changes since the 0.33.1 release.)

Further configuration reloads don't make any difference, but there's obviously something changing in how the effective font size is being calculated on startup versus after a configuration reload.

[LawnGnome]

I will say, though, that otherwise this feels really good. The extra sharpness with the fractional scaling is great, and I haven't noticed any other bugs thus far. (Albeit I'm not going to be testing things like resizing, since I generally just have one big terminal in a workspace.)

[kovidgoyal]

It wont be exactly the same precisely because of the support for fractional scaling, without it the scale used to calculate the font size was the rounded up one, now its the fractional one. And the algorithm for scaling the font size at render time and post-facto in th ecompositor after rendering are unlikely to yield the exact same results. One actually resizes the font, the other is an image resize.

As for the font size being different at startup, that is strange, can you post the output of running kitty with --debug-rendering. It might be because Wayland's fractional scale support is really weird. They have it for windows but not for monitors, so you can only know the actual scale of a window some arbitrary time after it is created and displayed. Maybe on your system the change is getting lost because of a timing issue.

[kovidgoyal]

And here is the fix (not tested): 353a56d

[kovidgoyal]

@neurocyte The only flicker I see while resizing the the shell prompt first blanking and then redrawing. Is that what you mean? If so, it is because of shell_integration that marks the prompt and on resize kitty blanks the prompt so that the shell can redraw it cleanly. kitty is fast enough that the user gets to the see momentarily blanked prompt and the redrawn one. This avoids much worse misbehavior when resizing, like misdrawn or repeated prompts. Easily tested by say running cat at the shell prompt and then resizing, in which case this flicker does not happen.

[neurocyte]

Yes, it was the prompt I saw flickering. I didn't occur to me that it was just the prompt. That is no big deal then.

[kovidgoyal]

This should fix the prompt flickering in most common cases: 684d28d

[real-or-random]

Are you saying the rendered font size changes when you change between a scale of 2 and 3 but not 2 and 2.5?

Exactly! But it's now fixed on e7fb437, thanks for the quick fix. I assume it was the same problem as reported by @LawnGnome. I had not tried Ctrl-Shift-F5.

[neurocyte]

This should fix the prompt flickering in most common cases: 684d28d

Looks good now.

I have done some testing on KDE now too. The blur on KDE is really slick. Nice!

[kovidgoyal]

On Fri, Apr 12, 2024 at 05:07:19AM -0700, CJ van den Berg wrote: > This should fix the prompt flickering in most common cases: 684d28d Looks good now. I have done some testing on KDE now too. The blur on KDE is really slick. Nice!

Credit for that goes to kwin developers :)

[LawnGnome]

And here is the fix (not tested): 353a56d

Yep, that fixed it for me. Thanks!

Here's the debug rendering log, just in case it's useful for anything else:

kitty --debug-rendering output

[0.033] Compositor missing capabilities: blur
[0.053] Creating window at size: 750x972 and scale 1
[0.085] XDG top-level configure event: size: 0x0 states: 
[0.085] XDG decoration configure event received: has_server_side_decorations: 1
[0.085] XDG surface configure event received and acknowledged
[0.085] Final window content size: 750x972 resized: 0
[0.085] Setting window "visible area" geometry in configure event: x=0 y=0 750x972 viewport: 750x972
[0.085] Attached temp buffer during window creation of size: 750x972 and rgba(255, 255, 255, 255)
[0.085] Waiting for compositor to send fractional scale for window
[0.086] XDG top-level configure event: size: 750x972 states: TOPLEVEL_STATE_ACTIVATED TOPLEVEL_STATE_TILED_LEFT TOPLEVEL_STATE_TILED_RIGHT TOPLEVEL_STATE_TILED_TOP TOPLEVEL_STATE_TILED_BOTTOM 
[0.086] XDG surface configure event received and acknowledged
[0.086] Final window content size: 750x972 resized: 0
[0.086] Setting window "visible area" geometry in configure event: x=0 y=0 750x972 viewport: 750x972
[0.086] Attached temp buffer during window creation of size: 750x972 and rgba(255, 255, 255, 255)
[0.088] Fractional scale requested: 180/120 = 1.50
[0.088] Resizing framebuffer to: 1125x1458 window size: 750x972 at scale: 1.50
[0.088] Preferred integer buffer scale changed to: 2
[0.116] OS Window created
[0.126] Child launched
[0.140] Waiting for swap to commit: swap has happened, window surface committed
[0.145] Changing cursor shape to: WP_CURSOR_SHAPE_DEVICE_V1_SHAPE_TEXT with serial: 0
ignoreboth or ignorespace present in bash HISTCONTROL setting, showing running command in window title will not be robust
[0.080] GL version string: '4.6 (Core Profile) Mesa 24.0.4-arch1.2' Detected version: 4.6

[kovidgoyal]

Closing as released in 0.34