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

121–130 of 134 posts

Re: Improving cursor rendering on Wayland

#121

Post by matheusmoreira »

bsder wrote: post #66
matheusmoreira wrote: post #60

Earlier quoted context omitted.

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

Well to me it sounds like a lot of other people also put in time and effort into making Wayland better, only to be consistently blocked by gnome/redhat at every turn.

It's not the first time I see people air their grievances like that so I gotta wonder why people keep working with them. Let red hat pay the developers to take Linux in whatever direction it wants. Other developers can go in some other direction that they agree with. The beauty of Linux is the kernel enables such a diverse user space. That's what I personally care about.

Re: Improving cursor rendering on Wayland

#122

Post by [deleted] »

immibis wrote: post #101
zamadatix wrote: post #14

Earlier quoted context omitted.

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?

[deleted]

Re: Improving cursor rendering on Wayland

#123

Post by immibis »

thayne wrote: post #109
chaorace wrote: post #37

Earlier quoted context omitted.

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.

Which is the problem most protocols solve by putting the essential things in core.

Re: Improving cursor rendering on Wayland

#124

Post by silon42 »

thayne wrote: post #100
vetinari wrote: post #77

Earlier quoted context omitted.

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.

I'm not opposed to having mechanism to opt in to client side decoration, but making it mandatory is problematic for several reasons: 1. Different apps will draw decorations differently, leading to a lot inconsistency. 2. It means apps designed for other environments that don't draw their own decorations won't have any decorations. 3. If your client doesn't use one of the big all encomposing gui toolkits (not every ap…

Even on a non-tiling WM, I'll rather have double decorations for GNOME apps than suffer the client side decorations.

Re: Improving cursor rendering on Wayland

#125

Post by immibis »

walteweiss wrote: post #114
prmoustache wrote: post #82

Earlier quoted context omitted.

Do we have to waste just for the sake of wasting?

Do you mean time and energy for optimising things that make no sense, so you have no time and energy to optimise things that make sense?

Not optimising things that "make no sense" is how we ended up with operating systems needing gigabytes of RAM just to boot, and AAA video games taking over 100GB each. A reasonably efficient system is the sum of reasonably efficient parts, or else you end up in UniformlySlowCode hell.

Re: Improving cursor rendering on Wayland

#126

Post by zamadatix »

immibis wrote: post #101
zamadatix wrote: post #14

Earlier quoted context omitted.

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?

The display server needs to be able to render the cursor or decide the cursor information even when no GTK (or other) apps are running. When it does so it needs to change the size of the cursor based on the display it's on. This size may not always be a whole number of pixels and may or may not change in the middle of a session. If you ever did cursor effects like macOS scaling the cursor on fast movement you'd need a way to handle that per frame size change request as well. In all it just doesn't make sense to move the logic for rendering the cursor into application frameworks.

I think it'd be best if "another vector format" was really "another cursor format which allows the actual cursor data to be tagged with a format". That way every time someone wanted to change the cursor protocol to allow compressed bitmaps or animated files or different vector formats it didn't require a whole new cursor file format to do it. Think something like MKV but for cursor data.

Re: Improving cursor rendering on Wayland

#127

Post by Findecanor »

Instead of SVG, I wonder if not the ideal format would be Haiku's Vector Icon Format (HVIF) [1][2]. It has binary files that are much smaller and it too supports multiple levels of detail for different sizes.

I heard somewhere that Haiku would use it for its own cursors, but my google searches for getting that verified have not been fruitful.

[1]: https://www.haiku-os.org/news/2006-11-06_icon_facts/

[2]: https://www.haiku-os.org/articles/2006-11-13_why_haiku_vecto...

Re: Improving cursor rendering on Wayland

#128

Post by vetinari »

rcxdude wrote: post #79
vetinari wrote: post #77

Earlier quoted context omitted.

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.

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.

Basically two:

1) Synchronization: when you are rendering decorations in a different process that the window content, you never get frame perfect. You can't synchronize both processes for each frame.

2) When painting using two processes, you need two surfaces. You just doubled your VRAM usage and the amount of blitting you need to do.

Now, decorations are not only the window chrome itself, but parts of them are font rendering (Qt renders fonts a little bit differently than Gtk, you can see the differences) and popup menus (when right clicking on the window chrome). The menus are a difficult thing; they basically pull in the entire respective UI framework (theming, sizing, font rendering, ...). So you do not really have a choice of unified look with server-side decorations; you have choice with cluttered mess between apps using different frameworks, or cluttered mess inside apps using different framework than the one used to render decorations.

So, how the other operating systems do it? They won't allow you to connect directly to compositor in the first place. You _must_ use the platform library, be it Cocoa or Win32 in order to be able to get a surface that gets displayed. And since you are already linking these libraries, they will paint the decorations for you -- unless you override it. All that is client-side, in the address space of your application, in your message queue.

Now, Windows does have a server-side fallback, when you app is not processing the message queue. Then it will paint the system decorations, but since your app is not responding, any synchronization is passe anyway.

So how to solve this in Linux? You will have as many looks, as many apps decide that they do not want to play ball, that they are a special snowflake, that need to avoid the "bloat" of frameworks. The cluttered mess of different UI styles and the permanently broken state of everything is a price you are paying for them to be able to do exactly that.

Otherwise, you would be able to reduce the looks to two (Qt and Gtk). When things would go very well, Qt could do what it does on other platforms and use Gtk+ look. That's about the only way to get unified look.

Re: Improving cursor rendering on Wayland

#129

Post by vetinari »

noisem4ker wrote: post #116
vetinari wrote: post #77

Earlier quoted context omitted.

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.

> Rendering decorations server-side is a really bad idea. Why?

See the answer above: https://news.ycombinator.com/item?id=39728575

Re: Improving cursor rendering on Wayland

#130

Post by vetinari »

thayne wrote: post #100
vetinari wrote: post #77

Earlier quoted context omitted.

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.

I'm not opposed to having mechanism to opt in to client side decoration, but making it mandatory is problematic for several reasons: 1. Different apps will draw decorations differently, leading to a lot inconsistency. 2. It means apps designed for other environments that don't draw their own decorations won't have any decorations. 3. If your client doesn't use one of the big all encomposing gui toolkits (not every ap…

1) They will anyway, see below: https://news.ycombinator.com/item?id=39728575

2) Only if they use server-side decorations only. In Wayland, client-side is mandatory and server-side optional. So if they do not have decorations, they are broken.

3) You client should use one of the big frameworks. On other operating systems, they are mandatory anyway. Only Linux allows your client connecting to compositor directly. Use that power responsibly. Frameworks bring lot of stuff implemented for you. If you reject that, it is up to you to implement that yourself.

4) You can't even with server-side decorations either.

Yes, with tiling, you get them. However, many apps have toolbar there, so you need it anyway.

Post reply on HN