Live data from Hacker News

Improving cursor rendering on Wayland

blog.vaxry.net

41–50 of 134 posts

Re: Improving cursor rendering on Wayland

#41
post #17

Earlier quoted context omitted.

It's the hyperland https://hyprland.org > config format.

Hmm, this leaves me with mixed feelings. It's obviously easier if everyone just adopts libhyprcursor instead of implementing a spec themselves and everyone having to iron out interoperability issues. Hyprlang doesn't look large, it's probably on the same order of magnitude as your average JSON decoder/encoder, but OTOH it's kind of a bespoke language versus other more "standard" options and I think this is likely to…

This is a first-party package from the Hyprland organization. This is meant to be used by people that use Wayland+Hyprland and want a better cursor. I don't think the idea is to make the package itself attractive but to make the Wayland+Hyprland switch attractive by saying: look, here are all the things we do better, including cursors.

Re: Improving cursor rendering on Wayland

#43
post #42

> A max 96x96 Bibata cursor, a single cursor, is about 2MB. Umm this does not pass smell test.. 96x96x4=36864 bytes of raw pixel data. How does that become 2MB?!

I have that exact icon theme installed, so I went and checked, and you're right. Most of the cursors look to be in the 160 KiB range (which includes all the sizes together), with only the ones that include animations getting into the MiBs

Re: Improving cursor rendering on Wayland

#44
post #3

The article essentially says--whether this is a good idea or not--that GTK is the one hold-out, which I wasn't really expecting as a punchline; why is GTK not implementing this?

That isn't really surprising to anyone who has been following how GNOME approaches wayland.

GNOME is also the one holdout that doesn't support server-side rendering of window decorations (like the title bar with buttons to close and minimize).

GNOME has pushed back on several wayland protocol extensions that all the other compositors supported.

Re: Improving cursor rendering on Wayland

#45
Some suggestions for improving adoption of this:

1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.

2. Have a shim layer so that hyprcursor cursors can be used by applications that use the XCursor API (maybe have a drop in replacement library for libxcursor that delegates to hyprcursor).

3. Have a specification so other implementations can use the cursor format as well, in case other compositors/clients don't like your implementation for some reason.

Re: Improving cursor rendering on Wayland

#46
post #45

Some suggestions for improving adoption of this: 1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library. 2. Have a shim layer so that hyprcursor cursors can be used by applications that use the XCursor API (maybe have a drop in replacement library for libxcursor that delegates to hyprcursor). 3. Have a specification so o…

> 1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.

Use XDG ini.

Re: Improving cursor rendering on Wayland

#47
post #17

Earlier quoted context omitted.

Hmm, this leaves me with mixed feelings. It's obviously easier if everyone just adopts libhyprcursor instead of implementing a spec themselves and everyone having to iron out interoperability issues. Hyprlang doesn't look large, it's probably on the same order of magnitude as your average JSON decoder/encoder, but OTOH it's kind of a bespoke language versus other more "standard" options and I think this is likely to…

This is a first-party package from the Hyprland organization. This is meant to be used by people that use Wayland+Hyprland and want a better cursor. I don't think the idea is to make the package itself attractive but to make the Wayland+Hyprland switch attractive by saying: look, here are all the things we do better, including cursors.

OK, but I am responding directly to the post itself when I say this. Specifically this:

> Will this ever be adopted?

> I don't know! All I know is that it's a clearly superior system that is easy to implement.

> The best path, in my opinion, would be to push for wp_cursor_shape adoption over at gtk. If gtk finally supports the protocol, almost all desktop apps that people might wanna use on Linux will be able to utilize hyprcursors via the compositor.

> Support from the toolkits themselves for hyprcursor itself is likely not going to happen, as hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard. Who knows? :)

On one hand, I agree with toolkits simply adopting wp-cursor-shape. This makes a lot of sense, and unlike with the CSD argument, I don't really think it would place a particularly hard burden on Mutter to just implement this protocol.

On the other hand, though, if other compositors want a better solution than XCursor, they either have to adopt this or something else, or invent their own system. And Hyprland, by virtue of being a fairly popular and pragmatic Wayland compositor, will no doubt collect a fair number of themes in the Hyprcursor format.

And based on this particular wording:

> All I know is that it's a clearly superior system that is easy to implement. ... hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard

This seems to suggest that Vaxry has:

- A belief that this really should be adopted, as a superior solution to cursor themes

- Some level of disdain for the idea that other developers might make their own standards instead of adopting this

Which honestly, is true... but that makes it all the more a shame that this probably won't happen for relatively unimportant reasons, meaning that likely, we'll end up with another cursor theme format later on that will be incompatible.

Not blaming them for not trying to do this as it seems Hyprland has mostly succeeded by simply blazing forward without gaining consensus, but there's a two way street to that approach IMO.

Re: Improving cursor rendering on Wayland

#48
post #8
post #4

Earlier quoted context omitted.

It's a wholly expected punchline to anything wayland: by most accounts Gnome is one of the worst offenders in the death-by-comittee wasteland that is standardising protocols in wayland.

As far as I can tell, nobody has filed an issue on Gitlab for wp-cursor-shape, nor posted an MR. https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?search=w... https://gitlab.gnome.org/GNOME/gtk/-/issues/?search=wp-curso... Nothing on Mutter either: https://gitlab.gnome.org/GNOME/mutter/-/issues/?search=wp-cu... https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?searc... It looks like the old GTK mailing lists w…

I disagree.

If GNOME does anything I personally don’t like it’s usually the result of a grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)

Re: Improving cursor rendering on Wayland

#49
post #38
post #6

Earlier quoted context omitted.

It's a Wayland problem if it is really problem at all though. The author complains that XCursor themes take too much space on disk (They will live uncompressed in VRAM anyways). Considering we are talking about Megabytes in the age of Terabytes HDDs, as long as you don't want to install thousands of XCursor themes on the same machine this is really a non-issue.

> Considering we are talking about Megabytes in the age of Terabytes HDDs, Most distributions still use a "Live CD" format, actually a "Live DVD" nowadays (with a few hacks to make it also work as a USB pen drive image), for their installers, and that limits the installation image size (which also includes enough packages for an offline install of a desktop environment) to a bit more than 4GB (they fit into a common…

Does it make sense though?

Any USB drive is so super cheap these days, you can easily get something like 128 Gb for $15. Even if you live in an area where it’s not as easy (e.g. not very developed places), you’re likely to find, say, 32 Gb for less than $10. So I don’t know, maybe someone needs that 4 or 8 Gb limitation, but I believe it’s a non-issue in most cases.

Also, on top of that, we do have a very speedy Internet I’m so many places. Which means if you’re limited here, you can go with the net-installer. If you’re limited on both, more likely it’s a very niche case and you can have a spare large disk to download everything offline.

Post reply on HN