Live data from Hacker News

Improving cursor rendering on Wayland

blog.vaxry.net

81–90 of 134 posts

Re: Improving cursor rendering on Wayland

#81
post #73

Surprised that Wayland would go the route of entirely deferring to the client for cursor rendering instead of providing a default implementation and exposing an api which client can use to assume control.

Wayland provides little by design, so this is quite typical. For example:

Screensharing is handled by pipewire [0], changing keyboard layouts aren't defined [1] by wayland, and generally anything Wayland devs think would 'corrupt' their protocol.

They leave most things to the compositor to implement, which leads to significant fragmentation as every compositor implements it differently.

Long gone are the days of xset and xdotool working across nearly every distro due to a common base, now the best you'll get is running a daemon as root to directly access `/dev/uinput` [2] or implementing each compositors accessibility settings (if they have them) as a workaround.

[0] https://superuser.com/questions/1221333/screensharing-under-...

[1] https://unix.stackexchange.com/questions/292868/how-to-custo...

[2] https://github.com/ReimuNotMoe/ydotool

Re: Improving cursor rendering on Wayland

#82
post #38

Earlier quoted context omitted.

> 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 Inte…

Do we have to waste just for the sake of wasting?

Re: Improving cursor rendering on Wayland

#83
post #9

"Well lol just draw a png haha Well, no, it's not that simple. Rasters are annoying. Raster means an image is stored with pixels, for example a png, or an mp4. The problem with rasters is that when you resize them, the computer has to take a wild guess at what it should look like." The problem with any display this software is going to run on is that it is also made with pixels. GTK foundation tried this approach for…

Yes; on lower-DPI displays, I certainly wouldn’t want a blurry SVG for a cursor. On 4K+ a vector format probably makes sense though.

Re: Improving cursor rendering on Wayland

#84
post #71

Earlier quoted context omitted.

Yes, i knew that. What is XDG ini?

The format they use. Find and view a *.desktop file, for instance.

*.desktop files are at most ini-like, they have a different specification that does not mention "INI" at all. What did formerly_proven refer to when saying "XDG ini"?

Re: Improving cursor rendering on Wayland

#85
post #8

Earlier quoted context omitted.

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)

> grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)

I must admit, I have wondered about the plausibility of this in the past. It seems like ironically, making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.

Is there any particular reason you think it couldn't be the case? I could definitely see it within the realm of possibility, especially since they maintain a huge chunk of the ecosystem nowadays (Fedora/RHEL, GNOME, LibInput, Kernel development, NetworkManager, Pulseaudio/Pipewire, Systemd, Wayland, and probably even more in the future.)

Re: Improving cursor rendering on Wayland

#86
post #29

Earlier quoted context omitted.

Or even better - remove features and then let someone else implement them.

Or remove features and don't let someone else implement them because you don't want to add in any configuration options.

Fornunately with Free software that doesn't matter too much because anyone can add a feature and if you don't want to accept it people can go to the other person's implementation instead.

I mean, isn't that how Cinnamon and Panteon and Unity and Cosmic and MATE were born?

Re: Improving cursor rendering on Wayland

#88
post #6
post #2

xorg and it's problems is so funny

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.

The one I made for myself decades ago is 632K, so possibly not even megabytes.

Re: Improving cursor rendering on Wayland

#89
post #54

Is displaying a few hundred KB of data on the screen really enough of a "problem" that it warrants putting image libs and potentially other dependencies in the middle of something as basic as cursor rendering?

Did you read the part that starts with “Well, no, it's not that simple”?

Re: Improving cursor rendering on Wayland

#90
Makes total sense to make cursors SVG, kind of crazy that nobody has done this b4 and that it's that outdated. Then yet again, handling SVG takes a lot more than some uncompressed images. So my question is how many resources, ram ... does it actually take to make some 200kb SVG as a cursor compared to some old uncompressed picture that might be bigger, but it's simply put on the screen 1:1. I guess it COULD be just about the unit process but if it's full SVG support than cursors can now be animated and be calculating all kinds of shit inside the SVG.
Post reply on HN