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 <[email protected]> on behalf of Simon Ser <[email protected]> Sent: Friday, October 12, 2018 4:06:28 PM To: Michael Arnold Cc: Emmanuel Gil Peyrot; Pekka Paalanen; Jonas Ådahl; [email protected] 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
