Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving cursor rendering on Wayland

blog.vaxry.net

Post reply on HN
Print view View original

31–40 of 134 posts

Re: Improving cursor rendering on Wayland

#31

Post by yxhuvud »

__s wrote: post #27
diggan wrote: post #25

Earlier quoted context omitted.

What exactly is insane here? That games/applications might want to draw custom cursors?

Any other system has a cursor hide feature that games/applications opt into. Everything else should have the compositor overlay the cursor This is particularly important because most applications aren't designed to render at monitor framerate, whereas games make an exception because they tend to be full screen applications & tend to render at a high framerate already

This is inconvenient for someone writing a custom client as it is yet another feature to support, but it really doesn't matter for anything that involves framerates unless you start to change the cursor every frame or so. Normally you will just respond to events and it takes a bunch of work and it is irritating you have to do it, but it isn't computationally costly as it typically won't happen often.

Re: Improving cursor rendering on Wayland

#33

Post by RVuRnvbM2e »

flohofwoe wrote: post #20
koterpillar wrote: post #16

How are cursors stored and drawn on let's say macOS? Honest question, comparing with X is easy but not exactly state of the art.

TL;DR: it's integrated with the rest of Cocoa. macOS cursors are provided by an NSCursor class which can either be one of the standard cursor image or provided through an NSImage object, which supports a number of data types (among the usual pixel-based formats like PNG or JPEG also PDF), it looks like applications can also register their own data formats via a class called NSImageRep.

Huh. So it's very similar to the Wayland protocol described in the blog post.

Re: Improving cursor rendering on Wayland

#34

Post by Jasper_ »

account42 wrote: post #19

> In the beginning of wayland, and in the core design spec, it's the client's job to draw the cursor. I mean, it kind of makes sense, as some apps might want to draw a custom cursor (e.g. games) Wait what. That's even more insane than client-side decorations.

No, it's not the client's job to draw the cursor. The client provides a surface, the same kind of thing as any other window, and asks for it to become the cursor. The client draws into the surface, but the placement and drawing of this surface to the screen is done by the compositor (most likely with an overlay plane).

This allows the application to customize the cursor, which happens more frequently than you might expect, e.g. dragging and dropping a file changes the "cursor" to include the little preview of the file. So the client already needs to learn how to render cursor images to composite the cursor image on top of the DnD preview.

One of Wayland's original core philosophies is to share behavior by shared library, rather than by protocol, because social agreement is already required, and is way better for a community long-term. So there is also a libwayland-cursor library that allows you to load Xcursors, which allows the client to do all the compositing and customization it needs, while still supporting a standard.

zwp_cursor_shape makes sense for a basic client without too many needs, but it's not a great idea for a full toolkit, otherwise DnD dragging (or any other case that requires compositing cursor images) will show a different cursor.

Also, SVG for cursors is not really a great idea.

Re: Improving cursor rendering on Wayland

#35

Post by Karellen »

jiehong wrote: post #10

What is this config.hl file format? At first, I thought it’s hlc [0], but I couldn’t find confirmation in the git repo either. [0]: https://www.linode.com/docs/guides/introduction-to-hcl/

The "Making themes" doc has examples.

https://github.com/hyprwm/hyprcursor/blob/main/docs/MAKING_T...

Looking at the full description of the format, it includes the ability to use nested config sections with `{ ... }`, which has some obvious benefits for some use-cases. But for the complexity needed for defining cursors, I don't see the benefit of `.hl` over fdo `.desktop` configs. In fact, it looks like you could parse the hyprcursor `.hl` config files with a `.desktop` parser? Which might be more palatable for cross-desktop support?

Re: Improving cursor rendering on Wayland

#36

Post by zamalek »

saurik wrote: 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 GTK is the one hold-out, which I wasn't really expecting

Gnome are consistently the hold-out, and are the source of much drama and chagrin in Wayland.

Re: Improving cursor rendering on Wayland

#37

Post by chaorace »

account42 wrote: post #19

> In the beginning of wayland, and in the core design spec, it's the client's job to draw the cursor. I mean, it kind of makes sense, as some apps might want to draw a custom cursor (e.g. games) Wait what. That's even more insane than client-side decorations.

The way I see it, it's a matter of who owns the chrome. Historically, we've seen that it is a losing battle to insist everyone uses your toys (e.g.: web input elements). I am not overtly opposed to keeping the protocol lean so long as there's a canonical and easy way to accomplish the basics.

Of course, because this is Wayland, one good idea suffers due to coexisting with other independently good ideas. The minds behind Wayland didn't want the protocol to ossify like X11 did, so they made extensions essential. If a given functionality doesn't need to be core, it's an extension.

Both great ideas in isolation, yet now, as a result, Wayland has trapped its ecosystem in a half-assed state of completeness. The one saving grace is that, unlike X11, things will actually improve over time as the gaps get filled in and older applications age out of the ecosystem.

Re: Improving cursor rendering on Wayland

#38

Post by cesarb »

sprash wrote: post #6
Vilian wrote: 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.

> 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 8GB USB pen drive). So it being the "age of Terabyte HDDs" does not matter, for packages expected to be installed on a normal desktop system.

Re: Improving cursor rendering on Wayland

#39

Post by generalizations »

vundercind wrote: post #22
saurik wrote: 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?

Gnome and Wayland (among other things) are the way they are, in part, to make running anything other than a standard-package-selection Red Hat unappealing to folks who might pay for Linux (enterprise). It’s good for them if their stuff’s a bit broken if you use other distros, or configs/software they don’t want to support, and if they cause integration pain and extra work for other distros. Or if that’s not the reaso…

It's a great strategy for sure. If I were running a software company that depended on software licenses and consulting fees for income, and I had to keep my stuff open-source, then what you outlined would be the best (and really, only) strategy for long-term survivability. It's a moat, and a good one, because it's plausibly deniable.

Re: Improving cursor rendering on Wayland

#40

Post by traverseda »

yxhuvud wrote: post #29
lupusreal wrote: post #28

Earlier quoted context omitted.

I think it's just a standard corporate insularness. Devs being paid to work on the software by the corporation view outsiders as a nuisance and certainly don't like outsiders giving them more work to do. They'd rather find justifications to remove features reinvent old systems to "reduce legacy cruft" (make their jobs easier.). Basically, it all makes sense if you assume standard commercial developer motivations.

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.
Post reply on HN