[HN Gopher] Improving cursor rendering on Wayland
___________________________________________________________________
Improving cursor rendering on Wayland
Author : moonleay
Score : 139 points
Date : 2024-03-14 09:14 UTC (1 days ago)
(HTM) web link (blog.vaxry.net)
(TXT) w3m dump (blog.vaxry.net)
| Vilian wrote:
| xorg and it's problems is so funny
| sprash wrote:
| It's a Wayland problem if it is really problem at all though.
| The author complains that XCursor themes take too much space
| _on disk_ (They will live uncompressed in VRAM anyways).
| Considering we are talking about Megabytes in the age of
| Terabytes HDDs, as long as you don 't want to install thousands
| of XCursor themes on the same machine this is really a non-
| issue.
| jiehong wrote:
| Another more important problem discussed is a lack of cursor
| sizes.
| cesarb wrote:
| > Considering we are talking about Megabytes in the age of
| Terabytes HDDs,
|
| Most distributions still use a "Live CD" format, actually a
| "Live DVD" nowadays (with a few hacks to make it also work as
| a USB pen drive image), for their installers, and that limits
| the installation image size (which also includes enough
| packages for an offline install of a desktop environment) to
| a bit more than 4GB (they fit into a common 8GB USB pen
| drive). So it being the "age of Terabyte HDDs" does not
| matter, for packages expected to be installed on a normal
| desktop system.
| walteweiss wrote:
| Does it make sense though?
|
| Any USB drive is so super cheap these days, you can easily
| get something like 128 Gb for $15. Even if you live in an
| area where it's not as easy (e.g. not very developed
| places), you're likely to find, say, 32 Gb for less than
| $10. So I don't know, maybe someone needs that 4 or 8 Gb
| limitation, but I believe it's a non-issue in most cases.
|
| Also, on top of that, we do have a very speedy Internet I'm
| so many places. Which means if you're limited here, you can
| go with the net-installer. If you're limited on both, more
| likely it's a very niche case and you can have a spare
| large disk to download everything offline.
| prmoustache wrote:
| Do we have to waste just for the sake of wasting?
| Izkata wrote:
| The one I made for myself decades ago is 632K, so possibly
| not even megabytes.
| destructionator wrote:
| this article is describing basically wayland adopting the x way
| of doing mouse cursors just with newer file formats lol
| saurik wrote:
| 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?
| rcxdude wrote:
| It's a wholly expected punchline to anything wayland: by most
| accounts Gnome is one of the worst offenders in the death-by-
| comittee wasteland that is standardising protocols in wayland.
| jchw wrote:
| As far as I can tell, nobody has filed an issue on Gitlab for
| wp-cursor-shape, nor posted an MR.
|
| https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?search=w.
| ..
|
| https://gitlab.gnome.org/GNOME/gtk/-/issues/?search=wp-
| curso...
|
| Nothing on Mutter either:
|
| https://gitlab.gnome.org/GNOME/mutter/-/issues/?search=wp-
| cu...
|
| https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?searc.
| ..
|
| It looks like the old GTK mailing lists were moved to
| Discourse at: https://discourse.gnome.org - so I tried
| searching wp-cursor-shape:
|
| https://discourse.gnome.org/search?expanded=true&q=wp-
| cursor...
|
| Maybe it can be found under other terms of course, but all
| I'm saying is, before picking up the pitchforks, maybe it'd
| be worth asking if they'd just accept an MR. Yes, I know many
| (myself included) are not thrilled with GNOME's approach to
| Wayland, but it's not going to be any more productive to just
| assume bad faith, at some point you just gotta push forward.
| PennRobotics wrote:
| https://gitlab.gnome.org/GNOME/mutter/-/issues/3276 ?
| jchw wrote:
| Gah, everyone uses different nomenclature when referring
| to Wayland protocols. Here's an MR for GTK:
|
| https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212
|
| No negative signals for either Mutter or GTK here, but no
| strong positive signals either. Let's make sure we add
| our thumbs up, at least.
| doublepg23 wrote:
| I disagree.
|
| If GNOME does anything I personally don't like it's usually
| the result of a grand conspiracy by Red Hat to make the
| Linux desktop worse, increasing their consulting profits.
| (/s)
| DaSHacka wrote:
| > grand conspiracy by Red Hat to make the Linux desktop
| worse, increasing their consulting profits. (/s)
|
| I must admit, I have wondered about the plausibility of
| this in the past. It seems like ironically, making a
| problem-free Linux would be a conflict of interest to
| Redhat, which makes more money the more problems it has.
|
| Is there any particular reason you think it couldn't be
| the case? I could definitely see it within the realm of
| possibility, especially since they maintain a huge chunk
| of the ecosystem nowadays (Fedora/RHEL, GNOME, LibInput,
| Kernel development, NetworkManager, Pulseaudio/Pipewire,
| Systemd, Wayland, and probably even more in the future.)
| vundercind wrote:
| 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 reason, the behaviors of a lot of projects
| RH birthed or heavily influence make a whole lot more sense if
| you assume it is and are fairly lacking in explanation
| otherwise. If it's not the case, they've managed to
| accidentally do something that's in their interest, I guess.
| lupusreal wrote:
| I think it's just a standard corporate insularness. Devs
| being paid to work on the software by the corporation view
| outsiders as a nuisance and certainly don't like outsiders
| giving them more work to do. They'd rather find
| justifications to remove features reinvent old systems to
| "reduce legacy cruft" (make their jobs easier.). Basically,
| it all makes sense if you assume standard commercial
| developer motivations.
| yxhuvud wrote:
| Or even better - remove features and then let someone else
| implement them.
| traverseda wrote:
| Or remove features and don't let someone else implement
| them because you don't want to add in any configuration
| options.
| tmtvl wrote:
| Fornunately with Free software that doesn't matter too
| much because anyone can add a feature and if you don't
| want to accept it people can go to the other person's
| implementation instead.
|
| I mean, isn't that how Cinnamon and Panteon and Unity and
| Cosmic and MATE were born?
| generalizations wrote:
| It's a great strategy for sure. If I were running a software
| company that depended on software licenses and consulting
| fees for income, and I had to keep my stuff open-source, then
| what you outlined would be the best (and really, only)
| strategy for long-term survivability. It's a moat, and a good
| one, because it's plausibly deniable.
| matheusmoreira wrote:
| So why don't people just stop caring what gnome thinks? Can't
| they just standardize the stuff regardless of gnome "holding
| out" on them or whatever it is they're doing? Do they need
| their permission or something? Just leave gnome behind.
| Doesn't really matter whether they catch up or not.
| bsder wrote:
| > So why don't people just stop caring what gnome thinks?
|
| Because Gnome is RedHat and ...
|
| 1) Because RedHat is one of the few companies that puts
| sustained, long-term funding beind developers working on
| Linux. As such, they get an outsized say in what goes on
| because _they are doing the work_. If you would rather that
| Linux go a different direction, fund a bunch of programmers
| and take it that way.
|
| 2) RedHat put in the work, time, and money to get certified
| in ways that allows it to be used for big business. That
| means adhering to things like accessibility, auditing, etc.
| If you get the same certifications, big business accounts
| can use your stuff instead.
|
| If you want people to ignore Gnome, all you have to do is
| fund a bunch of Linux developers to do all the work they
| are doing. Easy peasy.
| johnny22 wrote:
| gnome folks are on the committees just like everybody else
| is. They don't have veto power in that way over the
| accepted standards, only in what they implement.
| zamalek wrote:
| > that GTK is the one hold-out, which I wasn't really expecting
|
| Gnome are consistently the hold-out, and are the source of much
| drama and chagrin in Wayland.
| thayne wrote:
| That isn't really surprising to anyone who has been following
| how GNOME approaches wayland.
|
| GNOME is also the one holdout that doesn't support server-side
| rendering of window decorations (like the title bar with
| buttons to close and minimize).
|
| GNOME has pushed back on several wayland protocol extensions
| that all the other compositors supported.
| krupan wrote:
| What else even uses Wayland? Sway?
| thayne wrote:
| Sway, KDE, a handful of other compositors based on wlroots.
| vetinari wrote:
| They did that for a reason. Rendering decorations server-side
| is a really bad idea. Just because X11 did it is not a reason
| to repeat the mistake.
|
| If other compositors want to do it, they have their optional
| extension for that. Eventually, they will find out why they
| shouldn't do it. With mandatory extension, there would be no
| way back, with optional, there is.
| rcxdude wrote:
| I've yet to see a good argument for why it's a bad idea. To
| me client-side decorations are mostly yet another way that
| the desktop is turning into a cluttered mess of different
| UI styles.
| mouse_ wrote:
| "Well lol just draw a png haha
|
| Well, no, it's not that simple.
|
| Rasters are annoying. Raster means an image is stored with
| pixels, for example a png, or an mp4. The problem with rasters is
| that when you resize them, the computer has to take a wild guess
| at what it should look like."
|
| The problem with any display this software is going to run on is
| that it is also made with pixels. GTK foundation tried this
| approach for years, putting all their eggs into this basket, and
| recently having a reckoning and admitting this approach has not
| been working. Pixels are here to stay.
| zamadatix wrote:
| By this argument now that GTK supports directly rendering
| vector fonts sharply at arbitrary pixel densities we should
| switch back to bitmap fonts so GTK fonts can be bitmap rescaled
| again. I.e. the recent GTK reckoning you're referring to is
| actually about avoiding an extra raster rescale for exactly the
| reasons quoted, not about wanting more of it.
| layer8 wrote:
| Yes; on lower-DPI displays, I certainly wouldn't want a blurry
| SVG for a cursor. On 4K+ a vector format probably makes sense
| though.
| jiehong wrote:
| What is this config.hl file format?
|
| At first, I thought it's hlc [0], but I couldn't find
| confirmation in the git repo either.
|
| [0]: https://www.linode.com/docs/guides/introduction-to-hcl/
| notresidenter wrote:
| It's the hyperland <https://hyprland.org> config format.
| jchw wrote:
| Hmm, this leaves me with mixed feelings. It's obviously
| easier if everyone just adopts libhyprcursor instead of
| implementing a spec themselves and everyone having to iron
| out interoperability issues. Hyprlang doesn't look large,
| it's probably on the same order of magnitude as your average
| JSON decoder/encoder, but OTOH it's kind of a bespoke
| language versus other more "standard" options and I think
| this is likely to hinder adoption more than anything else.
| It's another "thing" whereas the desktop is already full of
| INIs, XMLs and JSON files.
|
| Then again, I have no stake in the matter. I think if Vaxry
| wants this to be adopted though, dropping it onto the world
| like this is probably not the most likely case to get there.
| It probably would've been worth bugging maintainers for other
| compositors (kwin, sway?) to see if they had any
| input/thoughts on the matter. I can only imagine Hyprlang as
| a dependency would've come up immediately as a discussion
| topic (I could be _very_ wrong though.)
| notresidenter wrote:
| This is a first-party package from the Hyprland
| organization. This is meant to be used by people that use
| Wayland+Hyprland and want a better cursor. I don't think
| the idea is to make the package itself attractive but to
| make the Wayland+Hyprland switch attractive by saying:
| look, here are all the things we do better, including
| cursors.
| jchw wrote:
| OK, but I am responding directly to the post itself when
| I say this. Specifically this:
|
| > Will this ever be adopted?
|
| > I don't know! All I know is that it's a clearly
| superior system that is easy to implement.
|
| > The best path, in my opinion, would be to push for
| wp_cursor_shape adoption over at gtk. If gtk finally
| supports the protocol, almost all desktop apps that
| people might wanna use on Linux will be able to utilize
| hyprcursors via the compositor.
|
| > Support from the toolkits themselves for hyprcursor
| itself is likely not going to happen, as hyprcursor is
| not made by a million-dollar non-profit entity via a
| 10-year-long bureaucratic process, unless somehow the
| developers over there decide it's more beneficial to use
| hyprcursors now rather than wait and develop their own,
| new standard. Who knows? :)
|
| On one hand, I agree with toolkits simply adopting wp-
| cursor-shape. This makes a lot of sense, and unlike with
| the CSD argument, I don't really think it would place a
| particularly hard burden on Mutter to just implement this
| protocol.
|
| On the other hand, though, if _other compositors_ want a
| better solution than XCursor, they either have to adopt
| this or something else, or invent their own system. And
| Hyprland, by virtue of being a fairly popular and
| pragmatic Wayland compositor, will no doubt collect a
| fair number of themes in the Hyprcursor format.
|
| And based on this particular wording:
|
| > All I know is that it's a clearly superior system that
| is easy to implement. ... hyprcursor is not made by a
| million-dollar non-profit entity via a 10-year-long
| bureaucratic process, unless somehow the developers over
| there decide it's more beneficial to use hyprcursors now
| rather than wait and develop their own, new standard
|
| This seems to suggest that Vaxry has:
|
| - A belief that this really should be adopted, as a
| superior solution to cursor themes
|
| - Some level of disdain for the idea that other
| developers might make their own standards instead of
| adopting this
|
| Which honestly, is true... but that makes it all the more
| a shame that this _probably_ won 't happen for relatively
| unimportant reasons, meaning that likely, we'll end up
| with _another_ cursor theme format later on that will be
| incompatible.
|
| Not blaming them for not trying to do this as it seems
| Hyprland has mostly succeeded by simply blazing forward
| without gaining consensus, but there's a two way street
| to that approach IMO.
| Karellen wrote:
| The "Making themes" doc has examples.
|
| https://github.com/hyprwm/hyprcursor/blob/main/docs/MAKING_T...
|
| Looking at the full description of the format, it includes the
| ability to use nested config sections with `{ ... }`, which has
| some obvious benefits for some use-cases. But for the
| complexity needed for defining cursors, I don't see the benefit
| of `.hl` over fdo `.desktop` configs. In fact, it looks like
| you could parse the hyprcursor `.hl` config files with a
| `.desktop` parser? Which might be more palatable for cross-
| desktop support?
| koterpillar wrote:
| How are cursors stored and drawn on let's say macOS? Honest
| question, comparing with X is easy but not exactly state of the
| art.
| flohofwoe wrote:
| TL;DR: it's integrated with the rest of Cocoa.
|
| macOS cursors are provided by an NSCursor class which can
| either be one of the standard cursor image or provided through
| an NSImage object, which supports a number of data types (among
| the usual pixel-based formats like PNG or JPEG also PDF), it
| looks like applications can also register their own data
| formats via a class called NSImageRep.
| RVuRnvbM2e wrote:
| Huh. So it's very similar to the Wayland protocol described
| in the blog post.
| aquova wrote:
| I've been experimenting with using Hyprland (a Wayland WM) on my
| laptop, and ironically Qt apps have been the ones that misbehave
| the most. Everything seems happy to use my preferred icon theme,
| but when hovering over a Qt app, the sizing greatly changes. I've
| mostly just gotten used to it (plus I never really got their
| overall theming correct) but I might have to try this out and see
| if it fixes my issues.
| diggan wrote:
| I gave Hyprland a try some weeks/months ago, and seemingly it
| had a video memory leak where after some hours of usage, it
| ended up taking more than 5GB of VRAM, with no signs of slowing
| down.
|
| I found one issue
| (https://github.com/hyprwm/Hyprland/issues/2945) mentioning
| something similar, but no resolutions as of yet, so not sure
| what's going on.
|
| Gnome3 doesn't manifest the same issue, so worth checking out
| if it happens to you if you're curious about moving from Gnome
| to Hyprland.
| account42 wrote:
| > 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.
| diggan wrote:
| What exactly is insane here? That games/applications might want
| to draw custom cursors?
| __s wrote:
| 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
| yxhuvud wrote:
| 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.
| RussianCow wrote:
| 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.
| Jasper_ wrote:
| 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.
| chaorace wrote:
| 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.
| planede wrote:
| Uh, if gtk apps draw the cursor client side, what happens if such
| an app freezes?
| yxhuvud wrote:
| Then the cursor doesn't change while it is above the app. You
| can still move it.
| bri3d wrote:
| 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 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.
| yxhuvud wrote:
| Oh, that looks really neat. No support in mutter yet, though
| I haven't seen any dismissal either, so who knows if it will
| eventually gain support.
| 3836293648 wrote:
| And this lead to stupid problems like the cursor sometimes
| just not rendering over some apps, like Alacritty
| magistr4te wrote:
| really not a fan of using the hyprland format for configuration.
| If this is supposed to be widely adapted, untying it from
| hyprland is necessary.
| zokier wrote:
| > 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?!
| aquova wrote:
| I have that exact icon theme installed, so I went and checked,
| and you're right. Most of the cursors look to be in the 160 KiB
| range (which includes all the sizes together), with only the
| ones that include animations getting into the MiBs
| dist-epoch wrote:
| I'm pretty sure that by "single cursor" they mean "cursor
| pack". Yeah...
| thayne wrote:
| Some suggestions for improving adoption of this:
|
| 1. Don't have a dependency on hyprlang. Other projects will
| probably be averse to that. Use a more common configuration
| language, using a common library.
|
| 2. Have a shim layer so that hyprcursor cursors can be used by
| applications that use the XCursor API (maybe have a drop in
| replacement library for libxcursor that delegates to hyprcursor).
|
| 3. Have a specification so other implementations can use the
| cursor format as well, in case other compositors/clients don't
| like your implementation for some reason.
| formerly_proven wrote:
| > 1. Don't have a dependency on hyprlang. Other projects will
| probably be averse to that. Use a more common configuration
| language, using a common library.
|
| Use XDG ini.
| blueflow wrote:
| What is XDG ini?
| reactordev wrote:
| XDG is the freedesktop group I believe.
| https://specifications.freedesktop.org/
| blueflow wrote:
| Yes, i knew that. What is XDG ini?
| nine_k wrote:
| The format they use. Find and view a *.desktop file, for
| instance.
| blueflow wrote:
| *.desktop files are at most ini-like, they have a
| different specification that does not mention "INI" at
| all. What did formerly_proven refer to when saying "XDG
| ini"?
| lpribis wrote:
| "INI" is not a specification. All INI parsers are
| slightly different, such that people refer to any file
| with [Section] Key = Value
|
| Format as "INI" or INI-like, including the xdg format.
| aquova wrote:
| It should be noted that the author is the creator of
| hyprland/hyprlang, so perhaps not too surprising that they made
| it a dependency, although I do agree with you.
| arisudesu wrote:
| 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?
| NoahKAndrews wrote:
| I think what X did is still the standard, which this article
| explains is pretty suboptimal. Sometimes crappy solutions stick
| around until someone pushes for something better.
| TylerE wrote:
| 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.
| radarsat1 wrote:
| Doesn't the CPU/GPU bottleneck which is already assumed to be
| slow actually provide the perfect opportunity for abstraction
| over a network protocol? Sending "what to draw" and "how"
| (shaders) over the wire infrequently and issuing cheap draw
| commands on demand? I think GPUs provide a _better_ situation
| for a network first model than was available when X was
| designed.
| TylerE wrote:
| You can send draw commands without making that the
| fundamental underlying operating model.
|
| GPUs are highly complex and performance under generic
| wrappers.
| uecker wrote:
| No, he is correct. The GPU on the other side of the PCI
| is a remote computer.
| TylerE wrote:
| Huge difference over operating over a PCI bus with
| gargantuan bandwidth and near zero latency, and working
| over random network connections.
| kllrnohj wrote:
| Only if everyone agrees on a central rendering model &
| feature set, which simply isn't the case. 2D rendering is
| not a solved problem, there are many different takes on it.
| Insisting all GUIs on a given device use a single system is
| simply not realistic, which is why nobody actually uses any
| of the X rendering commands other than "draw pixmap" (aka,
| just be a dumb compositor)
| Spunkie wrote:
| Is displaying a few hundred KB of data on the screen really
| enough of a "problem" that it warrants putting image libs and
| potentially other dependencies in the middle of something as
| basic as cursor rendering?
| minitech wrote:
| Did you read the part that starts with "Well, no, it's not that
| simple"?
| matheusmoreira wrote:
| > instead of being a caveman and making symlinks all over the
| place
|
| And what's wrong with that?
| TZubiri wrote:
| 1968: Mother of all demos presents mouse
|
| 1980: Personal Computers with mouse become popular, apple Lisa,
| Microsoft Windows 1
|
| 2000: Touch devices with stylus are popular
|
| 2007: Apple releases Iphone with finger touch
|
| 2015: Conversational interfaces like Alexa, Siri start becoming
| available.
|
| 2022: ChatGPT presents a huge tech improvement in conversational
| interfaces.
|
| 2024: "Actually let's rebuild this technology from the 80s from
| the bottom up. That's what we need"
|
| I do not regret moving away from open source/free software.
| sp1rit wrote:
| The thing I like about the Xcursor image format is that it so
| extremely simple[0]. Every semi-competent developer should be
| able to implement a parser/writer for the format in under an
| hour.
|
| But encoding the images with PNG does make sense, given the wide
| availability of libpng and the potential file size savings. I
| don't know how the feel about SVG support. One the one hand using
| vector graphics for cursors seems like a great idea but SVG is a
| _very_ complex format, with the only real parser available being
| librsvg, which massively increases toolchain complexity. Too bad
| PostScript doesn 't support transparency.
|
| [0]:https://www.x.org/releases/X11R7.7/doc/man/man3/Xcursor.3.xh.
| ..
| layer8 wrote:
| > PostScript
|
| I'm not sure we want a turing-complete language as a cursor
| format. ;)
|
| But I agree that a simpler vector format than the kitchen sink
| that is SVG would be good.
| open592 wrote:
| Surprised that Wayland would go the route of entirely deferring
| to the client for cursor rendering instead of providing a default
| implementation and exposing an api which client can use to assume
| control.
| DaSHacka wrote:
| Wayland provides little by design, so this is quite typical.
| For example:
|
| Screensharing is handled by pipewire [0], changing keyboard
| layouts aren't defined [1] by wayland, and generally anything
| Wayland devs think would 'corrupt' their protocol.
|
| They leave most things to the compositor to implement, which
| leads to significant fragmentation as every compositor
| implements it differently.
|
| Long gone are the days of xset and xdotool working across
| nearly every distro due to a common base, now the best you'll
| get is running a daemon as root to directly access
| `/dev/uinput` [2] or implementing each compositors
| accessibility settings (if they have them) as a workaround.
|
| [0] https://superuser.com/questions/1221333/screensharing-
| under-...
|
| [1] https://unix.stackexchange.com/questions/292868/how-to-
| custo...
|
| [2] https://github.com/ReimuNotMoe/ydotool
| jorvi wrote:
| I believe the Wayland spec writers / devs themselves have
| admitted that due to how strenuous working on X ended up
| being for them, they erred too much on the cautious side and
| underscoped Wayland.
| layer8 wrote:
| Since the Xcursor format is extensible, why not just define new
| chunk types for PNG and SVG? Such an approach could provide two-
| way compatibility.
| redder23 wrote:
| Makes total sense to make cursors SVG, kind of crazy that nobody
| has done this b4 and that it's that outdated. Then yet again,
| handling SVG takes a lot more than some uncompressed images. So
| my question is how many resources, ram ... does it actually take
| to make some 200kb SVG as a cursor compared to some old
| uncompressed picture that might be bigger, but it's simply put on
| the screen 1:1. I guess it COULD be just about the unit process
| but if it's full SVG support than cursors can now be animated and
| be calculating all kinds of shit inside the SVG.
| Someone wrote:
| > Makes total sense to make cursors SVG s/SVG/a
| vector format/
|
| I would think hard before supporting full SVG, as it opens a
| can of worms.
| https://www.w3.org/TR/SVG11/script.html#ScriptElement: _"A
| 'script' element is equivalent to the 'script' element in HTML
| and thus is the place for scripts (e.g., ECMAScript)"_
| Eduard wrote:
| I want a color-inverting cursor for Wayland. MS windows has it
| for 30 years.
___________________________________________________________________
(page generated 2024-03-15 23:00 UTC)