Comment Re:I still don't see what's wrong with X (Score 1) 226
You are repeating yourself. Learn to have a discussion: This implies replying to the things I wrote.
You are repeating yourself. Learn to have a discussion: This implies replying to the things I wrote.
Well, the users who actually do work with their computer probably do not comment as much... For speed, let's just wait for the benchmarks.
You are mostly right about open source. I am not telling people where to spend their time. I merely pointing out that there are users which depend on features which are not supported by Wayland. And - as such a user - I would find a switch to Wayland unfortunate.
What makes me angry is that people say that this discussion is not based on facts. The statement that network transparency is already broken is - as such - obviously not true. (and yes, I use modern GTK3 and Qt4 and other applications over the network - so far there is no problem.) The statement that Wayland will be much faster is atleast questionable.
You are also right, that Xrender was implemented to save network transparency a decade ago. Xrender is an excellent example how you can develop a protocol in a backwards compatible way without breaking existing features.
Because you obviously were mixing pixel scraping (used by RDP) with pixel pushing.
Quoting yourself: "Why? RDP also pushes pixels"
Doesn't it push the pixels over the network after scraping them?
You were also obviously confusing using Xrender to push pixels and using Xrender in a way which leads to low bandwidth usage.
Again, quoting yourself The term "software rasterizer" does not necessarily imply that it does not use Xrender.
Which is true. I don't see any confusion here on my part. Pixels can be pushed over the network and used in different ways on the server usind Xrender or not. Exactly as I said: the term "software rasterizer" does not imply exactly what is done.
Using the X protocol for a screen scraper is a bad ideia:
a) it does not provide means to compress the image on the wire.
This is true, but if used with ssh -X there would be some compression at a lower level. Also adding an extension to transfer compressed images would be very easy.
b) the display X server won't always keep the contents of the window. Eg, if you minimize and then restore a window, the display X server may require the contents of the window to be re-send, although they haven't been changed by the application.
Yes, but the application can store stuff at the X server and then later access it. I know, I wrote such code.
I really can't fathom why you insist on using the X protocol for a pixel scraper. There isn't anything new here. We have a bunch of pixel scrapers around for a long time (VNC, RDP, Xpra and, to some degree, NX) and they've all found it useful to use a specific protocol.
Because using X would backwards/forwards compatible, cross-platform, widely supported on UNIX/Linux (so far), and effortless (just use ssh -X). It also would keep the door open for applications which want to do something more clever than pixel scraping.
Some people like RDP because despite being owned by MS (and subject to patents) the FreeRDP project provides a good implementation of the RDP protocol, which AFAIK, compares favourably with other pixel scrapers.
Last time I tried to connect to a Windows server from Linux it simply did not work. But I am not opposed RDP. But I like X more because of the aforementioned reasons.
I am merely pointing out that I use network transparency on a up-to-date Linux system (not with gnome3 but with gnome3 applications). So the statment that network transparency is already broken is obviously false. If he said something else then it was not me who put it out of context.
I also like how I am modded troll merely for pointing out that it works for me.
So he hacked X to make it work in wayland - among many other things he does with X. This does not imply he gave up working on X in favour of Wayland. A better indications about doing the development activity and who is doing what are the mailing lists:
http://lists.x.org/archives/xo...
http://lists.freedesktop.org/a...
The idea that all/most X hackers gave up on X and are now working on Wayland as its successor is far from the truth.
Also - maybe I gave a false impression - but I am not opposed to Wayland. It is rather nicely designed and well written piece of software. What makes me angry is the idea that it is declared the future of Linux we all have to switch to when it clearly also has some downside, e.g. broken compatibility and network transparency. But those things are not openly discussed, instead they are "adressed" by FUD such as "network transparency is already broken". Oh, you are using it? You must be a lier because Daniel Stone told us it is already broken.
I don't see why you think I am mixing this up. I understand this well and fully agree with your description. What I meant is that you can implement method 3 without having a special protocol but by using the X protocol. The local pixel scraper would compute the changes could use the X protocol (instead of its own special protocol) to transfer them to any standard X server. The X protocol can be used to copy stuff on the server around when some screen region moved without retransmission of the data or update only parts of the window which have changes etc...
Or in other words, you could do the same as RDP but using X as protocol even for clients which are not optimized for remoting (while keeping the door open for clients which want to support this even better). And I am not sure why people like RDP so much, it is a proprietary and patent-protected (with a free license under some conditions) protocol from Microsoft with a lot of extensions (if people joke about the print server in X and then point to RDP I can only lough - because RDP has it too)
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
Now re-guess how many applications would adopt it in the name of smoother faster and (I'll admit this will creep in) shinier UI animations if it didn't break something in the process?
The fact that most of the X-window system isn't hardware accelerated is really nothing to be very proud of. In any case it's not the job of the application, it's the job of the toolkit or framework to do that.
Not many. Also most users don't care about about shinier UI and turn effects off and most distributions went back on desktop effects in their default applications. But there is another more important thing wrong with your comment: Wayland will not offer smoother or faster effects. This is a myth. You can do exactly the same things with X. Wayland will simplify things on the developer side by getting rid of old cruft (at the cost of backswards compatibility), but it will not make things fundamentally faster or smoother.
Well, I also find strange that people say they see no difference.
I see no difference on my work or home network. I admit (and have done so several times in this thread) that the experience is different if you have high latency. The Wayland proponent's argument seems to be that because it does not work well in all cases, it is ok to break it for the other use cases as well. Since I am using it just fine, I am not happy about that kind of argument.
From the top of my head, GTK3 applications are the only ones based on a modern toolkit that still run very well.
Yes, also Qt4 seems to work well, I don't know about Qt5. It would be a shame if they broke it.
The fact that Qt5 needs libXrender doesn't mean it has a Xrender based backend. AFAIK, Qt5 only has two backends: software rasterizer and OpenGL. I've never seen any evidence of other backends.
The term "software rasterizer" does not necessarily imply that it does not use Xrender. Also both could work over the network, but I haven't tried any Qt5 application so I do not know how well this works.
http://qt-project.org/wiki/Qt5...
Trying to forward Wayland clients over the X prototol is dumb.
Wayland clients (application) do nothing but to push pixmap buffers to the server. Try to forward that directly over the network in any shape or form and you get terrible performance.
Why? RDP also pushes pixels and it supposed to be faster than traditional X remoting (also whenever I tried to use it it never worked for some stupid compatibility reason) . Also Xrender essentially pushes pixels and works well - atleast for Gtk. The question is only how to push the pixels. The X protocol is really very flexible, so I think one could make this fast, e.g. only transmit changes.
The only solution is either to have a pixel scrapping mechanism or to have Wayland clients (applications) support some other protocol. Which most Wayland clients (applications) already do: they support X.
Yes, a pixel scrapping mechanism which then send the pixels using X is what I had in mind.
Hey, if you like RDP better, why don't you just use it. There are clients for X. I am not the one who wants to break your user experience. All I am asking for is that you don' please break mine, because for me X works just fine.
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
You know, this discusson is rather surreal. I run remote applications right now and you guys keep telling me it is broken. It is like sitting in an airplane and your seat neighbor claims that flying is actually impossible.
Ofcourse. This is not about the power of the device. My phone runs X just fine too. The point is that when you are intel or collabora and your customers are people who build entertainment systems for cars, TV set-top boxes, or mobile devices, then the UNIX legacy, which includes network transparency, and backwards compatibility, or support for customizable window managers, etc... just does not have any priority. Getting rid of all that complexity is then a rational choice. For the Linux desktop this would be a major loss. But this is not a market which counts and half of the users can be fooled into thinking that Wayland would be faster than X and network transparency is broken already.
Bengie believes,
1) X devs with decades of understanding and benchmarks claim X has horrible bottlenecks that can make Wayland 10x-100x faster for cases that are becoming more common
because he read it on the internet somewhere but doesn't bother to give a source.
2) Uecker claims X is fine because he installed X
Indeed. I know that X works fine because I use it - even over the network. If somebody comes a long and tells you that something you do is actually impossible you know they are full of shit.
Then half of the windows on my desktop cannot actually exist...
That's not what he meant I think.
Modern X applications (well, the toolkits) are resorting so much to simply pushing bitmaps to the X server that X is becoming unusable over the network.
I always find it strange that people make such claims. I use X over the network and I do not feel any difference to local clients. I might not work as well on your network, but claiming X is "unusable" or "network transparency is broken" just plain ignores that it works very well for some of us.
Eg, the Qt developers found sometime ago that their client side rendering backend was much faster for local usage than the Xrender backend. So they made it the default for Qt4.4 And for Qt5 they didn't even bother with a Xrender based backend.
That does not seem to be true: http://qt-project.org/doc/qt-5...
The client side rendering backend pushes so much data Kate is actually painful to use over a Gigabit Ethernet local network, don't even mention working from home. And this can be said for many other applications I use daily.
I use gnome software such as nautilus, evince, eog, gedit over the network just fine. I just installed kate to test and it also works
perfectly... I could not notice any difference to a local client. Your Gigabit ethernet must be much slower than my gigabit ethernet....
I run applications remotely on a daily basis. But now it's mostly under Xpra instead of plain X forwarding.
Good performance over the network is buried very deep in the priority list of most graphical application developers, if it's on the list at all.
And an Xpra like solution is something you can implement for Wayland.
Unfortunately, rewriting the GUI over and over again seems high on the priority list of graphical application developers. I actually hope somebody just implements a solution which uses the X protocol to forward Wayland clients remotely...
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?
