51–60 of 134 posts
Why are all these problems? Wasn't this solved already years ago in another software, I mean, Xorg? Why do we need to revisit the problem again?
Uh, if gtk apps draw the cursor client side, what happens if such an app freezes?
Basically, in the "old Wayland way", the Wayland compositor gave the client a surface and said "hey, draw something into this and I'll make it your cursor" and then the compositor well, composited it, using either true hardware cursor or an overlay layer of some kind. If the app froze, the cursor would still move, it just might not be updated. This seems clean architecturally but turns out to suck because now every client needs some kind of cursor drawing library in it, hopefully the same one everyone else is using so that cursor theming works and you don't get a different default mouse cursor in every app.
So then Wayland introduced wp_cursor_shape, which is where the client instead says "hey, draw a 'standard pointer' cursor over me please." But, the "old" client-drawn way is still supported and used, for example in GTK apps.
This proposal seems to just be a really complicated recommendation to change the file format used behind wp_cursor_shape, and a plea for "old" apps to either adopt this format/library or stop using client rendering. I think that switching to wp_cursor_shape pretty much Makes Sense for most apps, but the article didn't really sell me on this file format.
Why are all these problems? Wasn't this solved already years ago in another software, I mean, Xorg? Why do we need to revisit the problem again?
For one, "network first" for a GUI is not a sane model, and that is only more and more true as more "compute" is pushed onto the GPU.
Why are all these problems? Wasn't this solved already years ago in another software, I mean, Xorg? Why do we need to revisit the problem again?
We're in the position in the first place due to Xorgs decades of highly dubious technical decisions. For one, "network first" for a GUI is not a sane model, and that is only more and more true as more "compute" is pushed onto the GPU.
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
Uh, if gtk apps draw the cursor client side, what happens if such an app freezes?
Clients draw the cursor image, they don't render it to the screen or blit it. Basically, in the "old Wayland way", the Wayland compositor gave the client a surface and said "hey, draw something into this and I'll make it your cursor" and then the compositor well, composited it, using either true hardware cursor or an overlay layer of some kind. If the app froze, the cursor would still move, it just might not be updat…
> A max 96x96 Bibata cursor, a single cursor, is about 2MB. Umm this does not pass smell test.. 96x96x4=36864 bytes of raw pixel data. How does that become 2MB?!
And what's wrong with that?
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…