Wayland's Weston Lands A Pipewire Plug-In As New Remote Desktop Streaming Option

[Guest]

Depends on whether you're recording a native Wayland window or an X one. OBS records X windows in XWayland just fine.

The interfaces for capturing the screen are there for your use, even if upstream OBS doesn't hook into them yet.

It doesn't seem like capture plugins are all that involved to write, with OBS: https://github.com/fzwoch/obs-gnome-screencast?files=1

No upstream support means no support as of now. And since I'm supposed to rely on Xwayland so much, why wouldn't I just use X11 instead? Nobody has ported dwm to Wayland, and it's impossible to properly port it while following the suckless philosophy.

I think X11 is one of the best things about U*IX systems, and trying to kill it will remove a huge chunk of their superiority. I have never seen anything that can match X11's flexibility.

[Guest]

Wayland + compositing will require less processing power than X without compositing does, partially due to the way wayland allows interacting more directly with the hardware (such as overlay planes).

Don't mistake the terrible X compositing process for what Wayland does - having that in a separate process causes major overhead and is impossible to fix in X, which is one of the reasons all the X devs wanted to move on to Wayland.

You could also skip out on a compositor, and get even better performance.

[pracedru]

You are confusing the libs with the server.

Please tell me where i'm confusing "libs with the server".

[Hibbelharry]

It's done on the GPU, so it's pure overhead.

Like displaying a picture. Pure overhead. You're right.

Most of the time there is no problem. But let's construct a vision of a high load scenario:

Imagine a car. You want to go uphill and have 4 tons of rocks in your trunk. You know this will get awkward. But instead of minding driving without the rocks or any solution minding the rocks at all you're telling the guy next to you to throw his chocolate bar out of the window.

That's not smart, and thats not the problem.

I'm bound by the GPU, so it makes sense to make it do only what I actually want it to do.

Except you will not be able to measure a meaningful difference...

I can't care less whether my screen tears, and the benefits of a compositor are nonexistent to me.

They are, and even if not, they're basically for free.

. I don't need to have memory buffers with contents of the windows I'm working with,

So you can't use x.org? Any modern Toolkit does just that, because the X11 philosophy doesn't work anymore since years, and they need to workaround that.

Your basic mistake: You say things are working bad in X, so they will work as badly in wayland. That's just not true. You'll need to get a fresh start with that.

[Weasel]

This is by design. Wayland is intended to abstract away from compositing paradigms that rely on an "absolute window position." https://www.youtube.com/watch?v=_FjuPn7MXMs

I know it's by design, I said it in the post you quoted... and that's exactly why Wayland belongs in the dumpster.

So far, there has been no demonstrated need for such an extension.

This is another reason Wayland belongs in the dumpster: ignorance. It has been said over and over again why such a feature is absolutely essential, for applications that want to dock themselves relative to each other or synergize.

Or, a much better example: Wine.

[Weasel]

Can you please elaborate a lot more instead just pure sensationalism? How would you fix Wayland to make it superior than the alternatives? Tell ya, Mr. SCIENTIST!

Why do I have to elaborate the obvious? It's stated right in the quote: querying absolute window positions is essential feature that is lacking by design in Wayland.

How to make it better? Maybe how about to add essential features like this that are missing compared to X11? Wow, look, shocking.

And yes it is absolutely essential. Wine needs it even for context menus.


But since it's "by design" then Wayland will forever suck, this isn't sensationalism, just facts. If a moron maintainer simply rejects adding these features "by design", then the project really has no hope. Ever. It doesn't matter how many patches you write. It won't happen. It's hopeless trash.

[Weasel]

I am curious to know why you need (as a client app) to know where other application windows are?

Maybe because your app is intended to work with other apps' windows, to enhance them or whatever?

This is the desktop, not some fullscreen independent-app mobile bullshit.

FWIW, Wine needs it to provide full Windows behavior, because Windows allows it, and plenty of apps do it. In fact, on Windows, it's not uncommon for an app to dock or overlay on another (and move with it), and some even hotpatch other apps or inject stuff (for example to provide better rendering quality).

[microcode]

I don't understand why I cannot disable the compositor under Wayland.

Because Wayland is a protocol for interacting with compositors. If your window is fullscreen, or the layer you presented is in a hardware overlay then it may not use "compositing" per se, but it's still a "compositor".

"Compositing" is not some scary mystical operation. Weston was buttery smooth in 2013 on first-gen mesa-supported Intel IGPs. If you're willing to waste GPU power drawing more frames than are ever presented, then you can incur the tiny cost of presenting those frames atomically.

On X, I don't use a compositor (in the XComposite sense), because for what I do it is unnecessary. On Sway and other properly implemented compositors, it is roughly the same, minus the occasional one-frame tear during an underrun.

No offense to Mutter devs, Mutter has a lot going for it, but I think Mutter on X has convinced a generation of users that compositing makes desktop computing feel noticeably worse in terms of and both latency and throughput.

[boxie]

Maybe because your app is intended to work with other apps' windows, to enhance them or whatever?

This is the desktop, not some fullscreen independent-app mobile bullshit.

FWIW, Wine needs it to provide full Windows behavior, because Windows allows it, and plenty of apps do it. In fact, on Windows, it's not uncommon for an app to dock or overlay on another (and move with it), and some even hotpatch other apps or inject stuff (for example to provide better rendering quality).

Sounds like you are grasping at straws tbh.

[Guest]

Because compositing is not a separate part unlike in X11. In Wayland compositing is quite different from how it's done with Xorg and compositing window manager and there is no overhead.

There is a good blog post about it but I'm on a phone and don't feel like searching for it right now. I may do that later if I don't forget.

Anyway the main difference is that in Wayland Windows are given buffers (that could, in theory, even be pointing directly to framebuffer). On X11 buffers are given by Xorg and compositor has to ask for them from Xorg. Then compisitor may draw them on root surface. This adds more overhead due to additional copies. Therefore you usually need to blit (~= copy memory) only once on Wayland and it's done by GPU since that's the fastest way.

If you think that compositing is all about non-essential graphical effects then you have to adjust your mental model. Of course it allows that and also some useful tricks like scaling and rotating which would add some overhead but they are not necessary. Compositing is really in it's core only about composing all windows to their own place on framebuffer.

I have to say I'm no compositor expert but that's about how I remember that it works.

Ok, I'll adjust my mental model from something that does what it must do (xorg) to something that doesn't do what it must do (wayland).