5 ms·
The problem with X11 drawing commands is that there are a lot of round-trips over the network. Client asks for something, has to wait for the server response be
by dyingkneepad 5y ago
The problem with X11 drawing commands is that there are a lot of round-trips over the network. Client asks for something, has to wait for the server response before proceeding, then it asks something else, etc. XCB tries to help mitigate problems that Xlib created that were not in the X11 protocol, but it's still highly inefficient.
In practice, running everything locally and then just streaming the framebuffer ends up being faster.
Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here.
- nybble41 5y ago> Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here. In practice the "fast-over-the-network" protocol ends up being HTTPS + HTML + CSS + JavaScript, with a web browser as the client.
- em-bee 5y agoi don't know why parent was being downvoted. this is exactly why i am building web applications instead of desktop apps if i expect to run the application on a remote machine. a very good example is the deluge torrent client. by concept it is a desktop gui application. but it is designed in a client-server mode that allows the actual gui to run anywhere and access a backend through a thin protocol that provides a much better experience than remote X would. it has both a traditional gui interface and a well designed webinterface. there is no reason we could not be designing more applications like this.
- sprash 5y ago> The problem with X11 drawing commands is that there are a lot of round-trips over the network. This is not a problem with drawing commands or the fact that the X11 wire protocol supposedly inefficient (it is actually very efficient). It is a problem of GTK and Qt that introduce unnecessary round trips. Both tooklits (which are mainly the reason the Linux never took off because they are pure garbage) never cared in the least about remote applications. As comparison libXt based toolkits like motif run perfectly fine over the network and are very responsive.
- md8z 5y agoI'd advise against using hyperbole and dismissing projects as "pure garbage". I tried to ask you this before but I would be really interested to know what your use case for motif is in 2021. That seems like a recipe for pain and frustration, significantly moreso than any pain and frustration you would have had with GTK and Qt.
- sprash 5y agoInstead of playing the strengths of the UNIX desktop they are purposefully omitting them and trying to be a subpar copy of Windows/Mac all while throwing backwards compatibility out of the window for no apparent reason on a regular basis. They are pure garbage to such an extent that they appear to be deliberate sabotage.
- md8z 5y agoI'm curious as to why you think Motif "plays to the strengths of the Unix desktop" or what those strengths would be. I don't believe Motif has ever been particularly popular among GUI developers, it seems to me the only reason it was used was because it was the only real option on Unix for a while. Also please avoid assuming bad faith and suggesting without evidence that something is "sabotage".
- destructionator 5y ago> while throwing backwards compatibility out of the window for no apparent reason on a regular basis. They are pure garbage to such an extent that they appear to be deliberate sabotage. This is exactly how I feel about Wayland. It is gratuitously incompatible and its proponents regularly lie about X to push it. Makes me think they want to give desktop Linux a finishing blow.
- md8z 5y agoI'm not sure who you are referring to when you say "proponents", Wayland and X are mostly being developed by the same people. I don't see why they would lie about their own software. Also, if you look into it, you'll find everything that was redesigned in Wayland and broke backwards compatibility was done for a reason.