<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css" style="display:none;"></style> </head> <body dir="ltr"> <div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr"> <div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;"> <p style="margin-top:0; margin-bottom:0"><span style="font-size: 12pt;">Hi Simon,</span><br> </p> <div><br> </div> <div>Sorry for not participating more activively in the discussion. Your summary</div> <div>makes sense to me.</div> <div><br> </div> <div>> Some people (from KDE, GLFW if I recall correctly) said</div> <div>> there's some overhead in loading cursors on the client-side (a few megabytes,</div> <div>> I/O when loading images) and that could be saved. </div> <div><br> </div> <div>Here at Qt, we got a bug report about suspiciously high memory consumption for</div> <div>very simple clients. As it turned out, over 8 MB was used per client just for</div> <div>the cursor theme. Multiple scale factors, animated cursors etc. add up to quite</div> <div>a bit. For some embedded setups with lots of clients, this is a problem.</div> <div><br> </div> <div>This is easily solved by using a more light-weight cursor theme, but anyways; it</div> <div>would be <span style="font-size: 12pt;">nice if there was one less pitfall.</span></div> <div><br> </div> <div>Judging from the discussion on IRC and your API drafts, it <span style="font-size: 12pt;">seems like you're</span></div> <div><span style="font-size: 12pt;">already taking care of this, but I would be very happy if </span><span style="font-size: 12pt;">changes to the</span></div> <div><span style="font-size: 12pt;">libwayland-cursor API would allow (or at least don't prevent) </span><span style="font-size: 12pt;">compositor-</span></div> <div><span style="font-size: 12pt;">provided cursor </span><span style="font-size: 12pt;">buffers transparently. i.e. solving the reduncancy </span><span style="font-size: 12pt;">problem</span></div> <div><span style="font-size: 12pt;">with minimal changes </span><span style="font-size: 12pt;">to toolkit/client code.</span></div> <div><br> </div> <div>Johan</div> <div><br> </div> <p style="margin-top:0; margin-bottom:0"><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px"></span></p> </div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> wayland-devel <wayland-devel-bounces@lists.freedesktop.org> on behalf of Simon Ser <contact@emersion.fr><br> <b>Sent:</b> Friday, October 12, 2018 4:06:28 PM<br> <b>To:</b> Michael Arnold<br> <b>Cc:</b> Emmanuel Gil Peyrot; Pekka Paalanen; Jonas Ådahl; wayland-devel@lists.freedesktop.org<br> <b>Subject:</b> Re: Possible Wayland Extension to publish Mouse Pointer Size</font> <div> </div> </div> <div class="BodyFragment"><font size="2"><span style="font-size:11pt"> <div class="PlainText">Hi all,<br> <br> We've had a chat about cursor images on IRC yesterday. I'll try to sum up what<br> we said. I've published the original logs too for reference [1].<br> <br> First, it's clear that a protocol is needed. As we discussed earlier, this would<br> allow:<br> * Consistent cursors across all clients<br> * Per-seat configuration<br> * Not cluttering the environment<br> * Live cursor theme changes<br> <br> I originally wanted to push forward a "compositor-side cursors" approach where<br> the compositor loads the cursor theme and allows clients to create wl_buffers<br> using this loaded theme. Some people (from KDE, GLFW if I recall correctly) said<br> there's some overhead in loading cursors on the client-side (a few megabytes,<br> I/O when loading images) and that could be saved. I assumed most compositors<br> loaded cursor themes. However, it seems that this design could get in the way of<br> protocol adoption because some compositors may not load cursor themes at all<br> (and still want cursor configuration) and some compositors use a client helper<br> to load cursor themes (e.g. Weston). This would make it more difficult (and<br> maybe less effective) to implement such a protocol. Additionally, this protocol<br> would be more complex to implement for compositors.<br> <br> In the end, Pekka and Jonas said we should have two protocols: a simple one used<br> to configure xcursor (basically just sending the theme name and size to the<br> client) and maybe a more complicated one (creating wl_buffers). The former would<br> be easy to implement for all compositors while the latter could be implemented<br> by a subset of compositors willing to support it.<br> <br> We also discussed how the new protocol should integrate with libwayland-cursor.<br> It would be nice to have libwayland-cursor automatically use the new protocol if<br> available. Currently the API looks like this:<br> <br> theme = wl_cursor_theme_load(theme_name, size, shm);<br> cursor = wl_cursor_theme_get_cursor(theme, cursor_name);<br> buffer = wl_cursor_image_get_buffer(cursor->images[frame_num])<br> <br> It's clear that this API is not suitable for this new protocol. We'd like to<br> extend it to allow the xcursor configuration protocol to be used, and if<br> possible allow in the future a compositor-side cursor extension to be used. This<br> could roughly look like something like this:<br> <br> manager = wl_cursor_manager_create(display, seat, scale, default_theme_name,<br> default_theme_size)<br> buffer = wl_cursor_manager_get_cursor(manager, cursor_name, frame_num)<br> <br> (This is just a draft -- all of this still needs to be discussed and is<br> incomplete)<br> <br> I think that's about it. Please reply to this email if you think I forgot<br> something, got something wrong or if something's unclear.<br> <br> I plan to work on a protocol proposal, and then on a libwayland-cursor API<br> extension. Let me know if you're interested in helping out!<br> <br> Simon<br> <br> [1]: <a href="https://sr.ht/Pz-j.txt" id="LPlnk476314" class="OWAAutoLink" previewremoved="true"> https://sr.ht/Pz-j.txt</a><br> <br> _______________________________________________<br> wayland-devel mailing list<br> wayland-devel@lists.freedesktop.org<br> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" id="LPlnk254576" class="OWAAutoLink" previewremoved="true">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br> </div> </span></font></div> </div> </body> </html>