Possible Wayland Extension to publish Mouse Pointer Size

[Johan Helsing]

Hi Simon,

Sorry for not participating more activively in the discussion. Your summary
makes sense to me.

> Some people (from KDE, GLFW if I recall correctly) said
> there's some overhead in loading cursors on the client-side (a few megabytes,
> I/O when loading images) and that could be saved.

Here at Qt, we got a bug report about suspiciously high memory consumption for
very simple clients. As it turned out, over 8 MB was used per client just for
the cursor theme. Multiple scale factors, animated cursors etc. add up to quite
a bit. For some embedded setups with lots of clients, this is a problem.

This is easily solved by using a more light-weight cursor theme, but anyways; it
would be nice if there was one less pitfall.

Judging from the discussion on IRC and your API drafts, it seems like you're
already taking care of this, but I would be very happy if changes to the
libwayland-cursor API would allow (or at least don't prevent) compositor-
provided cursor buffers transparently. i.e. solving the reduncancy problem
with minimal changes to toolkit/client code.

Johan


________________________________
From: wayland-devel <wayland-devel-bounces at lists.freedesktop.org> on behalf of Simon Ser <contact at emersion.fr>
Sent: Friday, October 12, 2018 4:06:28 PM
To: Michael Arnold
Cc: Emmanuel Gil Peyrot; Pekka Paalanen; Jonas Ådahl; wayland-devel at lists.freedesktop.org
Subject: Re: Possible Wayland Extension to publish Mouse Pointer Size

Hi all,

We've had a chat about cursor images on IRC yesterday. I'll try to sum up what
we said. I've published the original logs too for reference [1].

First, it's clear that a protocol is needed. As we discussed earlier, this would
allow:
* Consistent cursors across all clients
* Per-seat configuration
* Not cluttering the environment
* Live cursor theme changes

I originally wanted to push forward a "compositor-side cursors" approach where
the compositor loads the cursor theme and allows clients to create wl_buffers
using this loaded theme. Some people (from KDE, GLFW if I recall correctly) said
there's some overhead in loading cursors on the client-side (a few megabytes,
I/O when loading images) and that could be saved. I assumed most compositors
loaded cursor themes. However, it seems that this design could get in the way of
protocol adoption because some compositors may not load cursor themes at all
(and still want cursor configuration) and some compositors use a client helper
to load cursor themes (e.g. Weston). This would make it more difficult (and
maybe less effective) to implement such a protocol. Additionally, this protocol
would be more complex to implement for compositors.

In the end, Pekka and Jonas said we should have two protocols: a simple one used
to configure xcursor (basically just sending the theme name and size to the
client) and maybe a more complicated one (creating wl_buffers). The former would
be easy to implement for all compositors while the latter could be implemented
by a subset of compositors willing to support it.

We also discussed how the new protocol should integrate with libwayland-cursor.
It would be nice to have libwayland-cursor automatically use the new protocol if
available. Currently the API looks like this:

    theme = wl_cursor_theme_load(theme_name, size, shm);
    cursor = wl_cursor_theme_get_cursor(theme, cursor_name);
    buffer = wl_cursor_image_get_buffer(cursor->images[frame_num])

It's clear that this API is not suitable for this new protocol. We'd like to
extend it to allow the xcursor configuration protocol to be used, and if
possible allow in the future a compositor-side cursor extension to be used. This
could roughly look like something like this:

    manager = wl_cursor_manager_create(display, seat, scale, default_theme_name,
        default_theme_size)
    buffer = wl_cursor_manager_get_cursor(manager, cursor_name, frame_num)

(This is just a draft -- all of this still needs to be discussed and is
incomplete)

I think that's about it. Please reply to this email if you think I forgot
something, got something wrong or if something's unclear.

I plan to work on a protocol proposal, and then on a libwayland-cursor API
extension. Let me know if you're interested in helping out!

Simon

[1]: https://sr.ht/Pz-j.txt

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181016/c05c93b0/attachment.html>