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

61–70 of 134 posts

Re: Improving cursor rendering on Wayland

#61

Post by TZubiri »

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.

Re: Improving cursor rendering on Wayland

#62

Post by TylerE »

radarsat1 wrote: post #55
TylerE wrote: post #53

Earlier quoted context omitted.

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.

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.

You can send draw commands without making that the fundamental underlying operating model.

GPUs are highly complex and performance under generic wrappers.

Re: Improving cursor rendering on Wayland

#63

Post by kllrnohj »

radarsat1 wrote: post #55
TylerE wrote: post #53

Earlier quoted context omitted.

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.

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.

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)

Re: Improving cursor rendering on Wayland

#64

Post by uecker »

TylerE wrote: post #62
radarsat1 wrote: post #55

Earlier quoted context omitted.

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.

You can send draw commands without making that the fundamental underlying operating model. GPUs are highly complex and performance under generic wrappers.

No, he is correct. The GPU on the other side of the PCI is a remote computer.

Re: Improving cursor rendering on Wayland

#65

Post by TylerE »

uecker wrote: post #64
TylerE wrote: post #62

Earlier quoted context omitted.

You can send draw commands without making that the fundamental underlying operating model. GPUs are highly complex and performance under generic wrappers.

No, he is correct. The GPU on the other side of the PCI is a remote computer.

Huge difference over operating over a PCI bus with gargantuan bandwidth and near zero latency, and working over random network connections.

Re: Improving cursor rendering on Wayland

#66

Post by bsder »

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.

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

Re: Improving cursor rendering on Wayland

#67

Post by 3836293648 »

bri3d wrote: post #52
planede wrote: post #21

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…

And this lead to stupid problems like the cursor sometimes just not rendering over some apps, like Alacritty

Re: Improving cursor rendering on Wayland

#68

Post by blueflow »

formerly_proven wrote: post #46
thayne wrote: post #45

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

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

What is XDG ini?

Re: Improving cursor rendering on Wayland

#69

Post by reactordev »

blueflow wrote: post #68
formerly_proven wrote: post #46

Earlier quoted context omitted.

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

What is XDG ini?

XDG is the freedesktop group I believe. https://specifications.freedesktop.org/
Post reply on HN