2 tier = server passes data to client all processing is done on the client client server = server does some processing and other processing is done client side. All graphic work is done client side. distributed = server passes graphical information to client all processing is done on the server but complex rendering is done on client. undistributed = server passes graphics to client. Processing and rendering done on server.
X11, the way you are using it is is undistributed. VNC is undistributed.
Really the Republicans argue for a race blind society. Lets put that to the test.
In Ohio the counties are voting on their hours. In every county the county boards have 2 democrats and 2 republicans. In every county every Democrat voted to extend voting hours. In the Republican / white districts the Republicans voted 2-0 consistently to extend hours. In the Democratic / ethnic districts Republicans voted 0-2 against extending hours.
Republicans want race blind in theory not in practice. In practice they support racism.
I don't know of anyone who has tested in isolation under real conditions. Wayland isn't finished, and apps aren't ported to Wayland. Anything done today would be a simulation and if you are going to simulate well you take things that take hundreds of a second on X11 and replace them with things that take billionths of a second on Wayland. Well yeah that's faster.
But there are more complete example. X11 using quartz-wm (i.e. essentially X11 on Wayland) vs. X11 as root windows (what X11 on Linux is like now) vs. Aqua (i.e. Wayland native). We do have apps that have been ported on which we can do measurements. The differences are profound and immediately noticeable. But more importantly remember even here what's an apple's to apple's comparison (excusing the pun). Wayland makes it easier to have all sorts of speed enhancing figures.
When the switch happens the differences won't be subtle, if they are Wayland failed.
That's what I mean by custom solutions around X. They couldn't get what they wanted from X. SGI ripped out huge chunks of the code and replaced it with a frame-buffer approach in Xsgi.
This is the system that Windows (GDI and now Metro) and OSX (Aqua) both use. Everyone knows it works.
Anyway 2 main performance improvements have been noted:
1) The one with buffering above. 2) Because the code for Wayland is smaller more of it fits in the processor or motherboard cache at any given time. Processor no-ops are noticeably declining with the GUI.
(2) was sort of an unexpected benefit of less code. No one thought Wayland would be small enough to get this benefit, after all it isn't written in assembly where you typically aim for this. It might not last very long as it will fall off exponentially as Wayland's code base gets bigger. But so far, yes they are getting it.
You aren't following client server. VNC, X11... are all applications designed around remoting a single user application. A client server application is one where there is a server interface and then an actual client program. Assuming you use an email application that's an example where you use client server. You are running a real honest to god application on your local machine which is doing light data manipulation and passing data back to another system which is doing the more serious / global data manipulations for multiple users.
I see. Yeah I agree Knoppix put several Linux utilities together to get that to work and always did an excellent job. And most importantly did it and then kept doing every boot.
Performance that would be impossible under X11. Especially as we are moving towards 10 megapixel worth of screens with 4 bytes of color information i.e. 40 megapixel the speed at which you can move information from one part of ram to another is starting to introduce latency. Reducing the number of buffering / copying instructions will have a huge impact on latency. The latency reductions are impossible under X11.
We have solutions that work for applications remotely. Things like J2EE actually accomplish what X was aiming for. Run the client locally and pass state information back to the server. If you need to distribute the client use something like Java, Flash,... designed to push binaries remotely.
And looking back at this. You actually specifically claimed this was a bandwidth problem, i.e. "when bandwidth becomes cheaper" not a deep structural problem.
A) There exist a list of 500 things that end users want in their display system that X11 didn't do or doesn't do well (circa say 2005). B) People working on X11 are (or would be) able to do 100 easy, 100 really hard because of X11 legacy code, 100 really hard because of support for network transparency, 100 medium hard because they have to use a different approaches than Windows or OSX, 100 are just impossible because of limitation in X11.
C) This group finally says, it simply is not worth it to keep fighting the battle with X11 anymore. D) Canonical loves the idea. Suse, Red Hat... think its a good idea because they want their 500 things. (These are end users for X11). E) The Wayland project starts and Canonical commits to be a flagship client for it.
Most app developers in Linux today don't push the video system hard, those that do prefer Wayland. Most app developers target KDE and Gnome and both of these platforms like the advantages that Wayland creates over X11 in terms of potentials for advantages things like cut and paste, drag and drop... But they are concerned about making their platforms (i.e. desktop and applications) non network transparent forever to take advantages. So consider them cautious supporters. The application developers for Gnome and KDE are all over the map but they are mostly too far downstream.
I don't think most Linux end users do use network transparency. There are a huge number that talk about the lack of various video features and attack X11 in sort of vague terms for things that quite often have nothing to do with X11. I don't know where they stand on these issues, but ultimately they do seem to want the X team to be more efficient.
Finally this is open source. End users get to decide the direction of a platform when they pay for it. In open source developers always get to decide. If you object to the direction, then jump in. In this case jumping in would be in 2015+ creating X / network transparent version of applications that migrate to Wayland.
To which you provide an absurd corner case and then claim that other people are making insane comments?
That's not an insane corner case. Video is one of the primary uses for computers. Accelerated video processing is now standard on Arm and becoming standard on Intel CPUs for a reason. This discussion is about whether X can offer acceptable performance for high demand work: games and video. Everyone knows X11 is fine for the kinds of video in system administration. Those sorts of uses aren't the reason to change video systems.
As for X being supported. Wayland includes an X11 Server. The issue is whether the applications will drop X11 apps, Wayland itself isn't the problem here.
The claim that I was responding to was that there was no lag over a LAN, not the open internet, a LAN. I gave a quick scenario to generate lots of lag on a LAN. That was the claim.
Talk to the people advocating for X11 to not make insane comments about no lag over LANs.
I don't buy over OSX release needing less resources. Heck a whole lot of people were complaining about the GPU requirements for 10.8 a month ago. The resource needs go up, not down. It makes better use of those resources. Like Oracle, Oracle is faster and faster hardware and faster hardware wants newer Oracle. Slowish hardware can do better with older Oracles.
First off this move towards Wayland is coming from the people who program X11 today. This is not a group of outsiders these are insiders. The people who support X11 as it exists today are not the people who have to handle implementing these features in the X11 codebase. Wayland is credible because of who is involved. This is not people saying Windows users would like X, but rather people saying Linux users would like X. This is not about appeal to the masses.
Since X uses shared memory locally, it's about as fast as anything is going to be.
No it isn't. Moving data between memory buffers is expensive if you want high frame rates. I'm on a laptop with 5mega pixel x 4 bytes of color. It uses screen virtualization which means it is drawing as many as 5 virtual screens for every physical screen. The fastest CPUs are still under 10 gigabit per second. I'm not seeing how shared memory is free with those ratios. Now consider next year we have retina 30" screens and 20 megapixel is going to need to be supported. And often multiple monitors....
People care enough about it that this part of Windows got "fixed".
Huh? Windows has high performance video that's not transparent. Not sure what you mean.
That kind of blows away and externally focused argument for "fixing graphics in Linux".
AFAICT the argument for Wayland came from within the X11 community not externally focused. It came from X developers who were implementing features of other GUIs and it taking 10x as long as (in their opinion) in should have to try and deal with the complexity of X saying they just wanted to toss X and start over. Most everything else is sort of post facto justification for X developers saying, "I want a smaller easier codebase". This isn't externally focused.
modify the Wayland spec to demand that every system that implements Wayland also includes VNC integrated with SSH. Problem solved, everyone can be happy.
I don't know if it should be part of the spec nor do I know if Wayland can demand anything but...
I think that's a great idea for a strong suggestion! Wayland be default should support VNC. ssh by default should use vnc (-v is taken, I think -X should remain with X11/X12 but I have no problem with -Z which is free). That solves most of the problem. I agree with you 100% FWIW.
Hopefully the distributions do this. This sounds like something RedHat (or interestingly enough Apple, which is big on VNC) might go for.
In my experience, the hard parts of making GUI code are dealing with multiple platforms (why would you want to write code for a single platform?) and going from functional-but-dull to snazzy-and-usable. The networking side of things (or not) is nowhere on that map.
I don't write software where I have to push large numbers of frames through per second either. On the other hand I use software where large numbers of frames per second matter. Interestingly enough I just got the mac retina. Because the retina is doing virtual adjustments (i.e. there are several virtual screens being drawn to by applications and those those are re-rendered to another virtual screen which gets pushed to the physical screen) I could easily see frame rate problems in even day to applications like video inside a web browser while scrolling before the driver improvements in OSX 10.8. What Apple did in 10.8 to get rid of those problems, would be impossible under X.
Kristian Høgsberg who wrote a lot of the X acceleration you are probably using was the one who started Wayland. He was frustrated about what he couldn't do. Under X applications are not able to control rendering. They cannot make decisions required to avoid visible tearing. They cannot force the X client to draw potential windows in advance to avoid lag.
Another problem is either the client and server (to use X terminology) share a video memory buffer or they don't. If they don't you pick up a lot of time passing information between them. Your CPU is probably no more than a few gigabytes per second, that is the maximum speed you can get data from one buffer to another under best conditions. And with screens that are 5 mega pixel x 4 bytes of color per pixel, every one way trip is is 1/100th of a second under perfect conditions. You aren't getting perfect conditions and 2 round trips is common. And if X wanted to implement something like the resolution system Apple for retina then it would be worse (though the CPU speed for memory is likely about double) because you could be rendering virtual screens as large as 14 megapixel with some round trip being 4 hops.... you could be talking flicker over 1/10th of a second.
I agree that I don't care about those... until the day that I do. Suppose I need to test the installation of some game or video editing software.
You live with something like VNC. The people who use those types of software have decided remote management isn't a feature they care about enough to sacrifice performance.
I'd rather have the mechanism for the user to do either.
You aren't really addressing the problem. Choosing to use X is making policy. Its making the policy to drop lots of frames in the video editor.
I would like to believe the people behind Wayland are smart enough to incorporate network transparency, but they seem to rather stubborn in omitting it
Its not a question of smart enough. A lot of the people implementing Wayland are the people who currently maintain X and have added features to it. It was working with X, and seeing how much harder it was to get X than Aqua or GDI to do something that convinced many of them that X had to go. What's happened is that on balance they've decided the disadvantages of network transparency outweigh the advantages.
I don't know about you, but that IS the killer feature that got it placed onto everyone's desks in my workplace. A lot of scientific and engineering software that needs some CPU power behind it never got ported to MS Windows. A lot of it makes more sense running on big noisy stuff in server rooms instead of desktop PCs anyway.
That's easy enough to implement as client server. You have a display client and a server which does the noisy stuff.
X works very well over a LAN, and, as bandwidth becomes cheaper, problems running over a WAN will go away
Its not generally a problem of bandwidth alone. Even with tons of bandwidth latency is a problem over WAN. IPv6 will make that somewhat better by reducing latency. Moving to fiber will make it somewhat better. On the other hand introducing more satellite, over the air, and wifi will make it worse. Now an MPLS will solve jitter but if jitter it gets even worse.
Now you are showing that you are out of touch. Tunneling X over SSH resolves the security problems and makes things much more simple (no more "xhost +" ). Over the LAN, I see no lag when using remote X tunneled over SSH.
SSH adds latency on both sides. Try doing 1080p real time video over SSH, and manipulate it and you'll notice some lag.:)
Slashdot Mirror
OK. We are kinda mixing here.
2 tier = server passes data to client all processing is done on the client
client server = server does some processing and other processing is done client side. All graphic work is done client side.
distributed = server passes graphical information to client all processing is done on the server but complex rendering is done on client.
undistributed = server passes graphics to client. Processing and rendering done on server.
X11, the way you are using it is is undistributed.
VNC is undistributed.
I'm saying you should be using client server.
Really the Republicans argue for a race blind society. Lets put that to the test.
In Ohio the counties are voting on their hours. In every county the county boards have 2 democrats and 2 republicans. In every county every Democrat voted to extend voting hours. In the Republican / white districts the Republicans voted 2-0 consistently to extend hours. In the Democratic / ethnic districts Republicans voted 0-2 against extending hours.
Republicans want race blind in theory not in practice. In practice they support racism.
I don't know of anyone who has tested in isolation under real conditions. Wayland isn't finished, and apps aren't ported to Wayland. Anything done today would be a simulation and if you are going to simulate well you take things that take hundreds of a second on X11 and replace them with things that take billionths of a second on Wayland. Well yeah that's faster.
But there are more complete example. X11 using quartz-wm (i.e. essentially X11 on Wayland) vs. X11 as root windows (what X11 on Linux is like now) vs. Aqua (i.e. Wayland native). We do have apps that have been ported on which we can do measurements. The differences are profound and immediately noticeable. But more importantly remember even here what's an apple's to apple's comparison (excusing the pun). Wayland makes it easier to have all sorts of speed enhancing figures.
When the switch happens the differences won't be subtle, if they are Wayland failed.
That's what I mean by custom solutions around X. They couldn't get what they wanted from X. SGI ripped out huge chunks of the code and replaced it with a frame-buffer approach in Xsgi.
This is the system that Windows (GDI and now Metro) and OSX (Aqua) both use. Everyone knows it works.
Anyway 2 main performance improvements have been noted:
1) The one with buffering above.
2) Because the code for Wayland is smaller more of it fits in the processor or motherboard cache at any given time. Processor no-ops are noticeably declining with the GUI.
(2) was sort of an unexpected benefit of less code. No one thought Wayland would be small enough to get this benefit, after all it isn't written in assembly where you typically aim for this. It might not last very long as it will fall off exponentially as Wayland's code base gets bigger. But so far, yes they are getting it.
You aren't following client server. VNC, X11... are all applications designed around remoting a single user application. A client server application is one where there is a server interface and then an actual client program. Assuming you use an email application that's an example where you use client server. You are running a real honest to god application on your local machine which is doing light data manipulation and passing data back to another system which is doing the more serious / global data manipulations for multiple users.
I see. Yeah I agree Knoppix put several Linux utilities together to get that to work and always did an excellent job. And most importantly did it and then kept doing every boot.
Performance that would be impossible under X11. Especially as we are moving towards 10 megapixel worth of screens with 4 bytes of color information i.e. 40 megapixel the speed at which you can move information from one part of ram to another is starting to introduce latency. Reducing the number of buffering / copying instructions will have a huge impact on latency. The latency reductions are impossible under X11.
We have solutions that work for applications remotely. Things like J2EE actually accomplish what X was aiming for. Run the client locally and pass state information back to the server. If you need to distribute the client use something like Java, Flash, ... designed to push binaries remotely.
And looking back at this. You actually specifically claimed this was a bandwidth problem, i.e. "when bandwidth becomes cheaper" not a deep structural problem.
There is no advantage to running X11 applications on Wayland. The advantage is for Wayland applications which will be much faster.
Its both. Think of it this way.
A) There exist a list of 500 things that end users want in their display system that X11 didn't do or doesn't do well (circa say 2005).
B) People working on X11 are (or would be) able to do 100 easy, 100 really hard because of X11 legacy code, 100 really hard because of support for network transparency, 100 medium hard because they have to use a different approaches than Windows or OSX, 100 are just impossible because of limitation in X11.
C) This group finally says, it simply is not worth it to keep fighting the battle with X11 anymore.
D) Canonical loves the idea. Suse, Red Hat... think its a good idea because they want their 500 things. (These are end users for X11).
E) The Wayland project starts and Canonical commits to be a flagship client for it.
Most app developers in Linux today don't push the video system hard, those that do prefer Wayland. Most app developers target KDE and Gnome and both of these platforms like the advantages that Wayland creates over X11 in terms of potentials for advantages things like cut and paste, drag and drop... But they are concerned about making their platforms (i.e. desktop and applications) non network transparent forever to take advantages. So consider them cautious supporters. The application developers for Gnome and KDE are all over the map but they are mostly too far downstream.
I don't think most Linux end users do use network transparency. There are a huge number that talk about the lack of various video features and attack X11 in sort of vague terms for things that quite often have nothing to do with X11. I don't know where they stand on these issues, but ultimately they do seem to want the X team to be more efficient.
Finally this is open source. End users get to decide the direction of a platform when they pay for it. In open source developers always get to decide. If you object to the direction, then jump in. In this case jumping in would be in 2015+ creating X / network transparent version of applications that migrate to Wayland.
To which you provide an absurd corner case and then claim that other people are making insane comments?
That's not an insane corner case. Video is one of the primary uses for computers. Accelerated video processing is now standard on Arm and becoming standard on Intel CPUs for a reason. This discussion is about whether X can offer acceptable performance for high demand work: games and video. Everyone knows X11 is fine for the kinds of video in system administration. Those sorts of uses aren't the reason to change video systems.
As for X being supported. Wayland includes an X11 Server. The issue is whether the applications will drop X11 apps, Wayland itself isn't the problem here.
The claim that I was responding to was that there was no lag over a LAN, not the open internet, a LAN. I gave a quick scenario to generate lots of lag on a LAN. That was the claim.
Talk to the people advocating for X11 to not make insane comments about no lag over LANs.
I don't buy over OSX release needing less resources. Heck a whole lot of people were complaining about the GPU requirements for 10.8 a month ago. The resource needs go up, not down. It makes better use of those resources. Like Oracle, Oracle is faster and faster hardware and faster hardware wants newer Oracle. Slowish hardware can do better with older Oracles.
First off this move towards Wayland is coming from the people who program X11 today. This is not a group of outsiders these are insiders. The people who support X11 as it exists today are not the people who have to handle implementing these features in the X11 codebase. Wayland is credible because of who is involved. This is not people saying Windows users would like X, but rather people saying Linux users would like X. This is not about appeal to the masses.
Solaris, SunOS, SGI, AIX, NeXT all had to implement custom solutions around X as well to get performance.
Since X uses shared memory locally, it's about as fast as anything is going to be.
No it isn't. Moving data between memory buffers is expensive if you want high frame rates. I'm on a laptop with 5mega pixel x 4 bytes of color. It uses screen virtualization which means it is drawing as many as 5 virtual screens for every physical screen. The fastest CPUs are still under 10 gigabit per second. I'm not seeing how shared memory is free with those ratios. Now consider next year we have retina 30" screens and 20 megapixel is going to need to be supported. And often multiple monitors....
People care enough about it that this part of Windows got "fixed".
Huh? Windows has high performance video that's not transparent. Not sure what you mean.
That kind of blows away and externally focused argument for "fixing graphics in Linux".
AFAICT the argument for Wayland came from within the X11 community not externally focused. It came from X developers who were implementing features of other GUIs and it taking 10x as long as (in their opinion) in should have to try and deal with the complexity of X saying they just wanted to toss X and start over. Most everything else is sort of post facto justification for X developers saying, "I want a smaller easier codebase". This isn't externally focused.
I'm not saying VNC, I'm saying real client server.
modify the Wayland spec to demand that every system that implements Wayland also includes VNC integrated with SSH. Problem solved, everyone can be happy.
I don't know if it should be part of the spec nor do I know if Wayland can demand anything but...
I think that's a great idea for a strong suggestion! Wayland be default should support VNC. ssh by default should use vnc (-v is taken, I think -X should remain with X11/X12 but I have no problem with -Z which is free). That solves most of the problem. I agree with you 100% FWIW.
Hopefully the distributions do this. This sounds like something RedHat (or interestingly enough Apple, which is big on VNC) might go for.
In my experience, the hard parts of making GUI code are dealing with multiple platforms (why would you want to write code for a single platform?) and going from functional-but-dull to snazzy-and-usable. The networking side of things (or not) is nowhere on that map.
I don't write software where I have to push large numbers of frames through per second either. On the other hand I use software where large numbers of frames per second matter. Interestingly enough I just got the mac retina. Because the retina is doing virtual adjustments (i.e. there are several virtual screens being drawn to by applications and those those are re-rendered to another virtual screen which gets pushed to the physical screen) I could easily see frame rate problems in even day to applications like video inside a web browser while scrolling before the driver improvements in OSX 10.8. What Apple did in 10.8 to get rid of those problems, would be impossible under X.
Kristian Høgsberg who wrote a lot of the X acceleration you are probably using was the one who started Wayland. He was frustrated about what he couldn't do. Under X applications are not able to control rendering. They cannot make decisions required to avoid visible tearing. They cannot force the X client to draw potential windows in advance to avoid lag.
Another problem is either the client and server (to use X terminology) share a video memory buffer or they don't. If they don't you pick up a lot of time passing information between them. Your CPU is probably no more than a few gigabytes per second, that is the maximum speed you can get data from one buffer to another under best conditions. And with screens that are 5 mega pixel x 4 bytes of color per pixel, every one way trip is is 1/100th of a second under perfect conditions. You aren't getting perfect conditions and 2 round trips is common. And if X wanted to implement something like the resolution system Apple for retina then it would be worse (though the CPU speed for memory is likely about double) because you could be rendering virtual screens as large as 14 megapixel with some round trip being 4 hops.... you could be talking flicker over 1/10th of a second.
I hope these two examples help. They have a good discussion: http://wayland.freedesktop.org/architecture.html
I agree that I don't care about those ... until the day that I do. Suppose I need to test the installation of some game or video editing software.
You live with something like VNC. The people who use those types of software have decided remote management isn't a feature they care about enough to sacrifice performance.
I'd rather have the mechanism for the user to do either.
You aren't really addressing the problem. Choosing to use X is making policy. Its making the policy to drop lots of frames in the video editor.
I would like to believe the people behind Wayland are smart enough to incorporate network transparency, but they seem to rather stubborn in omitting it
Its not a question of smart enough. A lot of the people implementing Wayland are the people who currently maintain X and have added features to it. It was working with X, and seeing how much harder it was to get X than Aqua or GDI to do something that convinced many of them that X had to go. What's happened is that on balance they've decided the disadvantages of network transparency outweigh the advantages.
I don't know about you, but that IS the killer feature that got it placed onto everyone's desks in my workplace. A lot of scientific and engineering software that needs some CPU power behind it never got ported to MS Windows. A lot of it makes more sense running on big noisy stuff in server rooms instead of desktop PCs anyway.
That's easy enough to implement as client server. You have a display client and a server which does the noisy stuff.
X works very well over a LAN, and, as bandwidth becomes cheaper, problems running over a WAN will go away
Its not generally a problem of bandwidth alone. Even with tons of bandwidth latency is a problem over WAN. IPv6 will make that somewhat better by reducing latency. Moving to fiber will make it somewhat better. On the other hand introducing more satellite, over the air, and wifi will make it worse. Now an MPLS will solve jitter but if jitter it gets even worse.
Now you are showing that you are out of touch. Tunneling X over SSH resolves the security problems and makes things much more simple (no more "xhost +" ). Over the LAN, I see no lag when using remote X tunneled over SSH.
SSH adds latency on both sides. Try doing 1080p real time video over SSH, and manipulate it and you'll notice some lag.:)