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

111–120 of 134 posts

Re: Improving cursor rendering on Wayland

#111

Post by thayne »

layer8 wrote: post #80
sp1rit wrote: post #72

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

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

I think the world is badly in need of a simple, modern, and widely available vector graphics format.

Re: Improving cursor rendering on Wayland

#113

Post by uecker »

TylerE wrote: post #65
uecker wrote: post #64

Earlier quoted context omitted.

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.

Certainly a huge difference, but if you want good performance you need to treat this as a remote buffer management problem in both cases.

Re: Improving cursor rendering on Wayland

#114

Post by walteweiss »

prmoustache wrote: post #82
walteweiss wrote: post #49

Earlier quoted context omitted.

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

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?

Re: Improving cursor rendering on Wayland

#115

Post by sebazzz »

Someone wrote: post #92
redder23 wrote: post #90

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

> 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)”

Most SVG renderers implement a subset of SVG, and that is just fine.

Re: Improving cursor rendering on Wayland

#116

Post by noisem4ker »

vetinari wrote: post #77
thayne wrote: post #44

Earlier quoted context omitted.

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.

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?

Re: Improving cursor rendering on Wayland

#117

Post by lionkor »

tadfisher wrote: post #107
lpribis wrote: post #96

Earlier quoted context omitted.

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

A subset, any TOML is a valid INI, but not nearly all INI are valid TOML

Re: Improving cursor rendering on Wayland

#118

Post by TylerE »

uecker wrote: post #113
TylerE wrote: post #65

Earlier quoted context omitted.

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

Certainly a huge difference, but if you want good performance you need to treat this as a remote buffer management problem in both cases.

Sorry, but I can’t take the suggestion that the PCI bus and the internet should be treated the same seriously. You’re telling 4 or 5 orders of magnitude difference. Maybe more on some specs.

It’s like saying you should use the same file access algorithms for a RAM disk and punch cards. No you shouldn’t!

Re: Improving cursor rendering on Wayland

#119

Post by destructionator »

TylerE wrote: post #53
arisudesu wrote: post #50

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.

> Xorgs decades of highly dubious technical decisions.

People like to say this, yet time and time again, X's design proves to be the superior one in the real world.

Some of it could use minor revisions (adding some image compression would be fine, etc), but it is hard to seriously say things are "highly dubious" compared to the competition.

Re: Improving cursor rendering on Wayland

#120

Post by destructionator »

cesarb wrote: post #38
sprash wrote: post #6

Earlier quoted context omitted.

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.

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

> So it being the "age of Terabyte HDDs" does not matter, for packages expected to be installed on a normal desktop system.

But neither does the "size on disk" because the ACTUAL size on disk might be reduced by gzip/bzip2/xz/zstd/whatever is invented later. Even if the program using the package doesn't support compression, it supports filesystems and filesystems often support some kind of transparent compression. It isn't a hard problem to solve.

Post reply on HN