Hacker News Reader

Comment by account42 | Hacker News Reader

> 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.

View on HN

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.

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.

> If a given functionality doesn't need to be core, it's an extension

In general, I think that is a good design.

The problem is the desktop compositors really struggle to agree on useful extensions. Which results in interoperability problems.

Which is the problem most protocols solve by putting the essential things in core.

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.

My understanding is that most modern games use the OS capabilities for drawing their custom cursor to the screen instead of just hiding it and drawing their own with custom code. The reason for this is that you don't want the cursor to lag when the game experiences delays or when the framerate is poor. Off the top of my head, Crysis was an example of a game that did this wrong, as the cursor would get really choppy in game menus when the framerate was poor.

Not the parent, but the problem is that applications that don't want to draw custom cursors are (or were except on gnome) still responsible for drawing the cursor. So instead of saying "i want a pointer cursor" when you hover over a link, you have to figure out what cursor theme the user is using, figure out what size you should use for the current screen resolution and scale, find the appropriate image for your desired shape, theme, and size, and render that to a surface. And hope you did all of that consistent with other apps the user uses.

Reply on news.ycombinator.com