Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving cursor rendering on Wayland

blog.vaxry.net

Post reply on HN
Print view View original

101–110 of 134 posts

Re: Improving cursor rendering on Wayland

#101

Post by immibis »

zamadatix wrote: post #14
mouse_ wrote: post #9

"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…

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.

Why can't GTK be asked for the pixel size the display server needs instead of converting them to yet another vector format and rendering them on the display server?

Re: Improving cursor rendering on Wayland

#102

Post by BearOso »

Xcursor doesn't predate PNG. Heck, it came alongside a tool, xcursorgen, that could be used to process pngs and generate the binary cursor files. Xcursor appeared somewhere around 2002-2003 as an extension of Xrender. Before that X had monochrome cursors.

There are some legacy X specifics in the theme format that would necessitate something more modern. IIRC, Xrender used a hash of hard-coded X pixmaps to find the cursor files to match. That's why some of the filenames are a long string of hex digits. The rest are predefined X cursor names.

Re: Improving cursor rendering on Wayland

#103

Post by viraptor »

animatethrow wrote: post #97
Eduard wrote: post #94

I want a color-inverting cursor for Wayland. MS windows has it for 30 years.

For many years the XOR sprite cursor was patented, but the patent seems to have expired in 2013. One of us should make the request to the GNOME/KDE/Wayland/DE people and link the expired patent: https://patents.google.com/patent/US5471570A/en EDIT: The linked patent seems to only cover 1 bit inversion, not full color inversion. I can't find the patent for the full color, but recall reading that a patent stopped the a…

That patent is only for MSB XOR though and seems to be only for hardware. That's not the only way to do it if someone wanted to achieve the result of better visibility.

Re: Improving cursor rendering on Wayland

#104

Post by panick21_ »

DaSHacka wrote: post #85
doublepg23 wrote: post #48

Earlier quoted context omitted.

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)

> 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 wit…

Because just factually Red Hat isn't working on many of these things alone. Most of these project have huge interest from many parties. And all those parties work daily with Red Hat and somehow the conspiracy remains undetected. The idea tat Red Hat corporate overlords can easily hurd the Gnome developers just isn't how the project is set up.

Many of the contributes to these project, even when being employed by Red Hat don't always do this as their primary job, many do it because they want to. It just so happens many people that love the linux ecosystem and linux itself work at Red Hat.

Other then that, many project that are very unifying and don't create much 'conflict' are also lead or worked on by Red Hat people. Pipewire for example has been the opposite of 'conflict' for the most part. LVFS is another good example. Flatpak/Flathub are another great example (Maybe Ubuntu is the evil agent of chaos). Systemd is also almost universally adopted by ever major distro even if it created much conflict.

Somehow people can't decide if Red Had is an evil dictator wanting to control everything or if they are deliberately creating 'conflict' so nobody is in control.

The simple reality is, there are a huge amount of people with incredibly different opinions in the Linux space. Even different people employed by Red Hat also don't always agree with each other. So who is really the true Red Hat conspiracy agent?

Difference on opinion is fine as long as people work on their own stuff, but when it comes to unification, like Wayland protocols it just gets really hard. The reason there is KDE and Gnome is because of fundamental disagreements about goals and that will be reflected in how they think wayland properties should be installed.

P.S:

> making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.

What is your actual evidence for this statement? If that was true, why are they working on all those projects. Objectively things like Pipewire, LVFS, Flatpak, Systemd have been major improvements to the ecosystem.

Re: Improving cursor rendering on Wayland

#105

Post by panick21_ »

vundercind wrote: post #22
saurik wrote: post #3

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…

Ah we are rolling out the old Red Hat conspiracy nonsense again. Classic HN.

I'm sure that why they invested in Flatpak, they just really want it to make it impossible for people to run non-standard packages on Red Hat. Makes total sense.

Re: Improving cursor rendering on Wayland

#106

Post by panick21_ »

matheusmoreira wrote: post #60
vundercind wrote: post #22

Earlier quoted context omitted.

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…

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.

They actually do that. Consensus is a goal. But if it can not be achieved then at some point people will just create a protocol anyway, even if Gnome doesn't implement it. People who claim this isn't the case haven't actually followed the space at all.

Of course issues still get stalled on this, because it takes a while to figure out that the disagreement is to fundamental. Often a compromise is actually found in the end.

Re: Improving cursor rendering on Wayland

#107

Post by tadfisher »

lpribis wrote: post #96
blueflow wrote: post #84

Earlier quoted context omitted.

*.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"?

"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.

Heck. TOML is a superset of it.

Re: Improving cursor rendering on Wayland

#108

Post by thayne »

notresidenter wrote: post #41
jchw wrote: post #17

Earlier quoted context omitted.

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…

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.

But if other compositor also used it, that would make it easier for hyprland users to use cursors that weren't designed specifically for hyprland. It would also be useful for apps that want to use custom cursor shapes (like, say, games).

Re: Improving cursor rendering on Wayland

#109

Post by thayne »

chaorace wrote: post #37
account42 wrote: post #19

> 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.

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 beh…

> If a given functionality doesn't need to be core, it's an extension

In general, I think that is a good design.

The problem is the desktop compositors really struggle to agree on useful extensions. Which results in interoperability problems.

Re: Improving cursor rendering on Wayland

#110

Post by thayne »

diggan wrote: post #25
account42 wrote: post #19

> 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.

What exactly is insane here? That games/applications might want to draw custom cursors?

Not the parent, but the problem is that applications that don't want to draw custom cursors are (or were except on gnome) still responsible for drawing the cursor. So instead of saying "i want a pointer cursor" when you hover over a link, you have to figure out what cursor theme the user is using, figure out what size you should use for the current screen resolution and scale, find the appropriate image for your desired shape, theme, and size, and render that to a surface. And hope you did all of that consistent with other apps the user uses.
Post reply on HN