-
> basically no good if you're any different from the people who hacked it together.
Why would you expect it any different? How can one implement things that they have no need or no hardware for? The entitlement is a bit jarring.
Also I think they merged something last year: https://github.com/swaywm/sway/pull/7681
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
I did some work to create a simple device to measure this some yeas ago. The intention was for developers to use it to regularly benchmark their software. It costs like 20 bucks and takes 10 minutes to build.
I might get to run some benchmarks myself next week.
https://jnsn.dev/posts/frametime/ with a follow-up in https://jnsn.dev/posts/fastisslow/ or if you just want to see the code without my jabbering: https://github.com/DelusionalLogic/Frametime
-
What components? Wayland is literally an XML protocol that turns an XML file into a method of communication. libwayland-server and libwayland-client only handle communication and the internal event loop. Its completely up to the developer to write the implementations of these functions and register them in the server.
Then a client is going to query the server and ask request to do stuff via a unix socket. In fact, you don't even need libwayland, you can raw dog it over sockets manually. The idea is that there are standard protocols that can be queried and used,and you can implement this in any environment you want to. You could write the "frontend" in html and JS and run a wayland compositor on the web (which has been done [1]), you could do it with text or anything really, most people use some graphics stack.
[1] https://github.com/udevbe/greenfield
-
On CS2 Wayland gave a major performance boost, but it's being held back by a regression since a change in device input layer.
https://github.com/ValveSoftware/csgo-osx-linux/issues/3856
From outside it's hard to tell if it's truly protocol differences or just the age of the implementations on X11, but when Wayland came out every project has claimed improvements over the old X11 stack. Also, from the early Wayland days presentations bashed the protocol as something that couldn't be fixed without a rework that was not going to happen due to the dead weight of backwards compatibility and awful older hardware.
As a user applications running on Wayland have consistently improved on how nice things feel if you don't miss your latency deadlines. It's easy to perceive on apps, and straight out obvious in games.
-
Although desktop GPU plane counts are much more limited, it's not as restricted as you're portraying. Here's the AMD SoC in the Steam Deck, for example: https://github.com/ValveSoftware/gamescope/blob/master/src/d...
Even though it's only 3 planes, they are relatively feature-rich still. In a typical desktop UI that would indeed be primary, cursor, and video planes. But if the system cursor is hidden, such as in a game, that frees up a plane that can be used for something else - such as the aforementioned game.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
