401–410 of 453 posts
Earlier quoted context omitted.
You honestly believe that Wayland software are not GPU-accelerated?
Our datacenters don’t have GPUs, Wayland doesn’t make my desktop’s GPU available to them, and local desktop-only software is getting pretty rare.
Earlier quoted context omitted.
>You can say this is a GNOME problem, or a distro problem, or whatever. But at the end of the day, I installed two of the most popular Linux distro's out there and my scrolling is literally unusable You chose GNOME , the answer is you are not the target of the GNOME project, they target people with weak minds that would instantly faint if they see a configuration screen with options. So you are using it wrong, with G…
> You chose GNOME , the answer is you are not the target of the GNOME project, they target people with weak minds that would instantly faint if they see a configuration screen with options. GNOME's problem is not the lack of configuration options, but lack of empathy. They stubbornly refuse to address (sometimes, even acknowledge) their own users' problems. > If you decide you want options try KDE [...] You don't sol…
I have been using Linux/Unix on desktop since the nineties, and while it has come a long way, it feels like that last 10-20 percent will never happen. It's that part that needs a manager with a large stick/carrot willing to make (informed) decisions and enforce them.
Earlier quoted context omitted.
Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency. And what if said app was actually a video player in it own self? Then you get to decode the video on server and re-encode it again for transport, whereas a primitive-centric protocol could allow decoding the original video directly on the client. The higher the window size the higher t…
> Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency. You can have your cake and eat it too: You can disable the compression if it's a problem. It's highly configurable if you want to play with it. The compression means trading a little bit of hardware resources at either end for a better UX (lower latency, higher throughput). > The hig…
Well you've of course lost the game at that point if your surface is very tiny, given you have no primitives to express "write text hello at x, y" e.g. for a terminal; without compression the bitmap presentation of a terminal—or a text document—is very large. Scrolling will damage the whole screen.
> Each surface has its own stream, and is updated independently. E.g., a video player on a webpage will generally be a subsurface, a context menu or plugin is a popup surface. They're all processed independently, with each their own damage tracking (and if applicable, video compression). If content is stretched or scaled up, only the original source buffer will be transmitted, allowing the display server to take care of this.
That's pretty nice and better than I assumed! Some hardware has limited number of hardware video encoders, though, for example in NVIDIA 1080GTX it's four for the _complete system_. I think for this reason waypipe reuses the contexts for different surfaces, resulting in lost video quality? Without reuse I expect one to run out of contexts quite fast—and then you spill to CPU.
Video sending can be a nice way to provide remote frames because it naturally batches all drawing operations into one compressed frame and really works if your task is to send 4k 60Hz video. But can it really beat display server -side composition or even things such as text rendering? As a tool in the toolkit it's a very nice thing to have, but it shouldn't be the complete toolkit. For X11 Someone(TM) could implement XPutVideo.
I think the bad performance of many X11 apps is not inherent to the protocol but inherent to the programs written in synchronous style (libX11 included; libxcb fixes this), assuming immediate access to the display server, instead of putting in requests while waiting for the answer for previous ones. Worst offender: Virtualbox. Access to a local surface and sending that surface as a whole can be a good solution to such code. And this kind of code is possibly so common because doing everything asynchronously can be tedious, and even more tedious in some enviroments such as C..
Earlier quoted context omitted.
Though, even there, networks are far faster than they used to be. Especially for the size is windows they used to push.
Latency hasn't really improved. Dial up or isdn to nearby cities was 25-50ms. Same as I get with hfc or 5g. Cable was slightly better where it was available. International pings got much worse from australia in the 2010s but since improved roughly back to where they were. Bandwidth has increased by 3 orders of magnitude though.
Earlier quoted context omitted.
Come on, it’s not like the linux user space was ever not fragmented. That’s sort of the deal with bazaar-style development. After enough time some best practices do solidify into standards, but it wasn’t overnight in X either, and first and foremost it wasn’t made with that in mind. Wayland has protocols which are queryable and provide a very good way of implementing more and more standard ones from the experimental…
> After enough time some best practices do solidify into standards, but it wasn’t overnight in X either, and first and foremost it wasn’t made with that in mind. Part of what drives me nuts about Wayland is they could have learned these lessons from X's history and actually had it in mind. Instead, they threw it all out without learning a thing.
Earlier quoted context omitted.
Come on, it’s not like the linux user space was ever not fragmented. That’s sort of the deal with bazaar-style development. After enough time some best practices do solidify into standards, but it wasn’t overnight in X either, and first and foremost it wasn’t made with that in mind. Wayland has protocols which are queryable and provide a very good way of implementing more and more standard ones from the experimental…
And? Just because the linux ecosystem is fragmented doesn't mean that new software has to be, too. The fact that developing a new compositor with wayland basically required wlroots to be even feasable for a one-man project is concerning enough. The amount of stuff you have to handle is insane compared to writing your own x-wm.
And developing a new compositor also does not require wlroots. Originally there was libweston, wlroots is just another option.
Earlier quoted context omitted.
If that's the case, that there's no common code they're all built on, then why does anyone talk about "Wayland" anything? All these conversations end up kinda pointless because of a sort of "it works on my machine[desktop environment]".
Well the conclusion is that it's never a wayland bug because wayland never defines X feature that users are missing.
Earlier quoted context omitted.
Sorry, I didn't clarify. The bug was fixed with some use of pixmaps, in other situations it's still broken. It sounds like the vast majority of apps you use are very old. Even plain productivity apps benefit from GPU rendering. If they don't it's because those apps are far behind, compare to things like Electron apps where everything has been GPU accelerated for quite some time because of Skia.
I find electron apps absolutely horrendous to use. The apps I use most are Zim, QtCreator, Strawberry, and the KDE apps: Okular, etc. - most of the time when I remote ssh it's for pavucontrol-qt, dolphin (the file manager) or mainly the app I develop, https://ossia.io (for instance for working on a show that is taking place over a raspberry pi). None of those force any kind of GPU rendering. Also apps that do gpu ren…
And that sounds like something is seriously wrong with your machine or your drivers. GPU rendering has massively improved performance and battery life on every machine I've ever tried. And especially on embedded devices with a low power mobile GPU, see for example here: https://social.librem.one/@dos/104984930233748319
Compositing should do so as well by avoiding unnecessary redraws. That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...
Earlier quoted context omitted.
The problem with X over the network is not bandwidth it is latency. The X11 protocol is very chatty so even very simple things will cause several roundtrips which makes X over the network so painful.
> The X11 protocol is very chatty so even very simple things will cause several roundtrips which makes X over the network so painful. This simply isn't true. Some operations require roundtrips, drag and drop comes to mind, but very simple things absolutely don't. Events come one way, draw commands go the other.
Essentially xlib is latency limited because its a synchronous protocol. Xcb can help if you redesign your applications for it, but we are talking about old applications (motif...)
Earlier quoted context omitted.
TBH This response is way too aggressive for the original comment. The facts stated are simply that today it is more efficient to encode video for remote graphical sessions because the X11 applications already changed a long long time ago to adapt to the modern world of GPUs and accelerated compositing. BW, latency, efficiency, everything became better because a super computer with thousands of cores can do that and l…
The problem is that the Wayland fans have a tendency (at least I feel) to significantly misrepresent things in their favor. Statements like "oh that's actually more efficient on Wayland". No, Wayland is incapable of the sorts of optimizations X can do by design . It is only more efficient if the X app is doing things in a specific way that doesn't take advantage of huge parts of the X protocol. Granted, most modern a…
While the reality is, that toolkits (and applications) used to use those APIs and were revamped to use the DRI APIs and general bitmap based windowing. The old APIs don't support double buffering, access to GPUs with modern APIs (both opengl[indirect sucks] and Vulkan). They don't provide modern font rendering, or any kind of graphical effect (distortions) that UI people might want to play with.
They would be significantly worse for anything displaying animations and one of the most common client libs (libx11) is serial and thus horribly latency sensitive.
The advantage of VNC isn't lossy compression. Which isn't forced by it either. But it handles networking better with bitmaps. And has improvements like acting as a screen/tmux style connectable session for graphical applications. Both VNC/RDB can also support showing the server's desktop if it has one, not just running other applications than currently open elsewhere.
The only advantage of old style X11 was that it's ubiquitous. But since it hasn't been used in ages since it doesn't work well with modern computers/UI frameworks that advantage is gone. And there's 0 reason to try and reimplement that in a new windowing protocol, when there's objectively better choices out there already. Local optimized windowing is a different beast than network capable.