| |||||||||||||
LPC: Life after XLPC: Life after XPosted Nov 6, 2010 14:44 UTC (Sat) by dskoll (subscriber, #1630)In reply to: LPC: Life after X by elanthis Parent article: LPC: Life after X
Plus, the network protocol _still_ is transmitting images all over the place, because modern apps still do a ton of image processing client-side And that's the real problem. If apps restricted themselves to using drawing primitives, the network wouldn't be a problem. Requesting the server to draw rectangles, polygons, etc. is extremely efficient and beats any kind of image compression. The problem is that apps decided they wanted fancy textures, background images, etc. So they essentially did all the rendering client-side and treated the X protocol as a big dumb pipe for shipping images. The correct approach is to move more support for fancy effects into the server so the clients don't have to render on their end. Unfortunately, there's no easy way to get around the use of textures and images, so here's a radical concept: Don't do it unless it's necessary (eg, for games.) And provide an escape-hatch (eg, shared memory) for local apps that really do need to sling lots of images and textures around.
(Log in to post comments)
LPC: Life after X Posted Nov 6, 2010 18:51 UTC (Sat) by drag (subscriber, #31333) [Link]
With X a lot of the problem for poor performance is latency, not bandwidth.
Sending a compressed texture that is something like 1024x768 over most networks is not going to be a problem any more in a lot of cases.
A lossless 1280x800 PNG image itself is only something like 260.1KB, which will transfer over most internet connections in a fraction of a second. High quality JPEG or WebP is even smaller and compresses much faster with relatively little discernible image problems.
It's when you run into issues with applications that want to have something like a animated menu or whatever that takes 100 redraws to go from start to finish. When your on a local machine something like that is just stupidly fast and it is irrelevant. When your over the internet something that used to take 0.1 second now takes 5 due to all the time lost to latency from going back and forth 'draw' 'finished draw' 'draw again' etc etc.
When the fastest network most people had was 10 people sharing a single 10Mb/s ethernet on a single hub with all of them sharing the same collision domain... THEN that was when X networking was very troublesome in terms of Mb/s used.
Nowadays even common consumer internet connections are faster then that.
But when you have 128msec latency and it takes 2000 round trips between a server and a client to draw a new web page on your browser.... THEN that is when you run into serious performance problems. It does not matter if your sending 10's of KBs of information or your just sending 5Bs each trip it's going to create huge delays.
Your far better off just taking a image of a 1024x768 desktop at 15 FPS, sending it over a network then working on some special protocol to relay input back. (I am not sure about SPICE or ICA, but I am pretty sure that their technology is more sophisticated then just that.)
This is why people report VNC working better then X when it's obvious that in terms of actual bandwidth used X is often going to be better.
But it's not like VNC or X is even close to the state of the art. Both of them are obsolete with their own set of problems.
Seriously, check out:
While people have been arguing over the merits of being able to remote access a single application over X vs a entire desktop over VNC.... the ability to remotely access your GUI over the internet has gone mainstream.
ANY PC, ANY Mac. Over your browser. Very simple to setup, relatively inexpensively, adequately secure, and good enough that the average customer can use it without pulling their hair out.
You can even do it on your iPhone or IPad....
Sure I am not going to use it and it's not suitable if you care about your security, but the networking aspect of X is far from unique or special anymore and it's performance in common situations is inadequate compared to contemporary solutions.
LPC: Life after X Posted Nov 6, 2010 18:55 UTC (Sat) by drag (subscriber, #31333) [Link]
Oh. And with my job I have the unfortunate requirement of having to use a number of windows-only applications on a regular basis.
Many of these applications are, in fact, virtualized and are individually remote'd to my desktop. The way it is done is completely transparent and there is not a single non-technical user on a corporate windows desktop that will be able to tell you what applications are remote and which ones are local. They will not even be able to tell you that they are using virtualized applications remotely at all.
The experience is completely integrated and there is no discernible way, in terms of performance or image quality, to tell the difference between local and remote apps.
LPC: Life after X Posted Nov 6, 2010 20:09 UTC (Sat) by dskoll (subscriber, #1630) [Link] It's when you run into issues with applications that want to have something like a animated menu or whatever that takes 100 redraws to go from start to finish. So it's just bad application design, then. Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it. Augmenting X or something similar to do that wouldn't be too hard. Somewhat off-topic: The contraction of "you are" is "you're", not "your". Sorry... just a pet peeve...
LPC: Life after X Posted Nov 7, 2010 4:39 UTC (Sun) by drag (subscriber, #31333) [Link]
> So it's just bad application design, then.
Sometimes. Or bad toolkit design, or maybe just a different theme that the user selected. And it's only bad design if your trying to run your software over a high latency link, otherwise it's probably quite sane.
> Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it.
Ya. OpenGL works surprisingly well sometimes. When AIGLX first was supported on my video card I ran 1024x768 Wolfenstien (Quake3 improved engine) over wireless. Worked very well and I got about 48-60 FPS.
It was playable for the most part, except the mouse lagged horribly. Keyboard input was fast and everything rendered fine otherwise.
Cairo and Clutter may help out quite a bit I suppose. I don't know for certain.
> Augmenting X or something similar to do that wouldn't be too hard.
It's called NoMachine NX. ;)
LPC: Life after X Posted Nov 7, 2010 7:14 UTC (Sun) by mfedyk (guest, #55303) [Link]
"It was playable for the most part, except the mouse lagged horribly. Keyboard input was fast and everything rendered fine otherwise."
that is because mouse processing takes so many round trips. to see this in action run dstat in a terminal, then move your mouse in a slow steady circle. your context switches per second will go up several hundred.
Facts of life Posted Nov 7, 2010 15:35 UTC (Sun) by khim (subscriber, #9252) [Link] So it's just bad application design, then. Sure. Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. No - because client-side solution is even simpler to implement. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it. No again. It's harder then to write the loop in program. Augmenting X or something similar to do that wouldn't be too hard. Well - can you do it in such a way as to make that it's easier to use your scheme then the naive animation implementation? You can not do that. Applications the sole justification for the fancy protocols, kernels and computers. Thus application writers dictate the rules. The only time when you can impose some restrictions is when they are caused by the law of physics. Because it's the only situation where all alternatives will impose the same restrictions so application developers will have no choice: otherwise the solution with the simplest usage from coder POV will always win. Witness fate of transputers and modern CPUs: today way have 16-way SMP on desktop while transputers offered 32 or 64 twenty years ago. Why we've only switched to SMP on desktop five years ago? Easy: before that it was possible to create more and more powerful UP machines. Only when UP machines hit the hard limit (speed of light, essentially) the direction changed. The same with animated menus today: application developers do and will continue to do applications which abuse fast CPU<->GPU connection till it works on desktop. They will not change their designs to accommodate "network transparency" - because their users mostly don't care. Thus all these ideas are not worth even talking about. If you can explain why/if they will stop working even on desktop - we can talk about redesign.
LPC: Life after X Posted Nov 8, 2010 4:46 UTC (Mon) by elanthis (guest, #6227) [Link]
Your so-called solutions goes against X's core design and principle, though. X doesn't do fancy effects, or any effects. X is mechanism, not policy. X is just a dumb rendering and event pipeline, by design.
The drawing primitives suck. You may not realize this, it's probably been a long time since you've seen or worked with a mainstream app that limits itself solely to the X drawing primitives (probably).
We don't want that. Users don't want that. The whole world -- other than a teeny tiny little fraction of people so small in significance as to be entirely irrelevant -- wants pretty UIs. Pretty UIs are actually _more usable_, as tasteful and skillful application of that prettiness results in more easily comprehensible and digestible information display and user focus direction. Put plainly: that shit matters.
If you're really that interested in continuing to use the Xerox Parc UI innovations and nothing else, knock yourself out. Arguing today that the people designing the graphics framework that goes beyond what X is capable of should instead stick to basic rendering primitives is every last bit as stupid as an old-time radio host arguing the radio is the best media ever while the Internet already started killing off TV which already killed radio dead.
The other problem is that you seem to have no grasp of how modern rendering is done. When I say "the client" does the rendering, what I actually mean is that the client is programming a GPU to do the rendering. What you end up wanting to do things your way then is a complete implementation of OpenGL over the pipe (which GLX is NOT in any way). You also completely ignored the parts about using the GPU for more than just graphics, too, including input handling and other general computation that you absolutely do not want in the display server, at all, period.
Your notion of how the desktop should work is wrong, dated, and (thankfully) totally irrelevant as you're not the one making the development decisions.
LPC: Life after X Posted Nov 8, 2010 9:27 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
You missed the point. He's proposing something like a motion-XRENDER, not animation done using the traditional drawing primitives. There is no reason modern UIs cannot be accommodated in X's extension framework. If people like you make "development decisions", we'll all be impoverished.
LPC: Life after X Posted Nov 8, 2010 16:44 UTC (Mon) by dskoll (subscriber, #1630) [Link] Your so-called solutions goes against X's core design and principle, though. X doesn't do fancy effects, or any effects. X is mechanism, not policy. X is just a dumb rendering and event pipeline, by design. Yeah, so? Change that aspect of X rather than throwing out the whole thing. Eventually, the best way to do things would be to have toolkits like Qt and Gtk be loadable modules that get installed in the X server rather than in client applications. That could greatly reduce the number of network round-trips required and greatly mitigate the latency problem. There are plenty of security concerns with this, of course. You wouldn't want to load Gtk or Qt into the X server unless it's running with your UID. But that's a much easier problem to solve and a much smoother transition to the future than throwing out X completely.
Smooth transition? From what? Posted Nov 9, 2010 15:23 UTC (Tue) by khim (subscriber, #9252) [Link] But that's a much easier problem to solve and a much smoother transition to the future than throwing out X completely. How come? You seem to assume that developers are using X and the only problem here is some shortcomings. Well, newsflash: no, they don't! Most applications today are written for Windows, PS3, Wii, iOS or Android. Not for X. Developers know toolkits (mostly GDI, but sometimes WPF or even Qt) and DirectX/OpenGL. They don't know X and then don't want to know X. This is fact of life. That's why all these band-aids are doomed: they impose burden on developers for megligible benefit. X is this thing down there which only exist to make our life misarable - this is POV of many (most?) developers. That's why it must be removed. Eventually, the best way to do things would be to have toolkits like Qt and Gtk be loadable modules that get installed in the X server rather than in client applications. But why introduce this stupid layer at all? Give the developers the means to run client app which talks with GPU and server - and he'll decide how to split the work. This is how it works on Windows, XBox360 and PS3 - and it certainly attracted significantly more developers then X redesigns ever could.
Smooth transition? From what? Posted Nov 17, 2010 7:11 UTC (Wed) by mcrbids (guest, #6453) [Link]
<QUOTE>Most applications today are written for Windows, PS3, Wii, iOS or Android. Not for X. Developers know toolkits (mostly GDI, but sometimes WPF or even Qt) and DirectX/OpenGL. They don't know X and then don't want to know X.</quote>
As an application developer with over 10 years of experience, I can say with certainty that this is not true, at least, not for me.
I don't write applications for Windows, PS3, Linux, Android, or *any* of the platforms listed. I write for the web browser! I write complex, data-driven applications and it's been a very, very long time since I wrote anything that wouldn't easily work on Win/Mac/Lin/Android/Iphone/Xbox and anything else with a reasonable browser.
The browser I most target is Firefox since it seems to be the most "Cross platform" although Chrome is close. I develop on Linux, it runs FF well, I don't worry about viruses and stuff like that, and can offer excellent compatibility with all my clients.
I don't want to replace X - I get the best of all possible worlds by making the specific rendering requirements of my applications something handled by the context of the user. And I use network transparency all the time - I can run several Firefox instances concurrently, on the desktop, as different users, without any danger of cookie or session interaction between browsers. As a web-based, network application developer, this is so incredibly useful!
LPC: Life after X Posted Nov 8, 2010 16:48 UTC (Mon) by dskoll (subscriber, #1630) [Link] Your notion of how the desktop should work is wrong, dated, and (thankfully) totally irrelevant as you're not the one making the development decisions. That certainly deserves a *plonk*. How about trying to stay civil?
LPC: Life after X Posted Nov 8, 2010 12:16 UTC (Mon) by dgm (subscriber, #49227) [Link]
> The problem is that apps decided they wanted fancy textures, background images, etc.
No, the problem is that users want this. You can blame them as much as you want, but it's all futile because in the end users still want that.
We have two options, we can build the stuff that's needed, of we can close our selves in our small ivory tower and wait until the world goes away. Which one do you want to chose?
LPC: Life after X Posted Nov 8, 2010 14:17 UTC (Mon) by madscientist (subscriber, #16861) [Link]
> We have two options, we can build the stuff that's needed, of we can
> close our selves in our small ivory tower and wait until the world > goes away.
The question is, build what's needed by WHOM?
You've had many, many people (myself included) state that what the users (us) want and need is the equivalent of today's network transparency features that X provides.
Yet many people here seem perfectly happy to ignore and pooh-pooh the users who really matter (those that we already have!) in some quest to obtain users that we don't have (those that use, and almost certainly will continue to use, Macs and Windows systems).
Ivory tower dwellers are people too!
WHOM is right :-) Posted Nov 9, 2010 15:57 UTC (Tue) by khim (subscriber, #9252) [Link] The question is, build what's needed by WHOM? Well, paying customers, obviously. Someone must pay for the development of the new hardware and software - and "he who pays the piper calls the tune". You've had many, many people (myself included) state that what the users (us) want and need is the equivalent of today's network transparency features that X provides. Sure. And there are many, many people who care about z80 programming on TI-84. Should we now think about z80 compatibility when we write USB drivers? Yet many people here seem perfectly happy to ignore and pooh-pooh the users who really matter (those that we already have!) in some quest to obtain users that we don't have (those that use, and almost certainly will continue to use, Macs and Windows systems). Huh? Where have you got this idea? Fact: most Linux users don't care about network transparency at all. Proof: more then 50 million Android phones were sold till now. There are less then 1.5 billions PCs in the world today so if we assume 3% of them are using Linux (typical estimate) we'll find out that there are more Android users then desktop Linux users. "Traditional Linux users" who care about network transparency and other such things are fast becoming minority - and this is exactly why we are talking about "life after X" today. We can, of course, say that we only care about ourselves and say that Android, ChromeOS, MeeGo and other such things are "not Linux" and "we don't care" - but it'll only mean that Linux will be left in dust and non-Linux (based on the same kernel!) will replace it.
WHOM is right :-) Posted Nov 12, 2010 0:40 UTC (Fri) by jmorris42 (subscriber, #2203) [Link]
> Proof: more then 50 million Android phones were sold till now.
Who cares. Seriously, counting Android as Linux users is as crazy as counting OS X users as UNIX, in both cases the *NIX underpinnings are only used as a hardware abstraction to host an alien environment to the typical Linux/GNU/X we typically call "Linux" as a shorthand. More power to em and all, but lets not make Apples to Oranges comparisions.
> "Traditional Linux users" who care about network transparency
Well take yer asses off and do your clone of all the bad ideas the existing userbase fled screaming from. It is Free Software after all. Here is a clue: Most of us came to *NIX because we saw the benefits and could also see the horrid mess the DOS/Windows world was. Why do we now want to toss one of the most wonderful ideas in computing to become more like the mass market drones? The network is the computer, the computer is the network. It isn't just a marketing slogan for some of us.
Besides, I never understood why suddenly everything needs to be rendered client side as bitmaps. Extend X to give it the mechanisms to support things it can't currently do and make sure they can run over the wire. Why can't X do the modern font tricks, compositing or whatever over the wire? Why isn't the default scalable SVG artwork? Isn't it normally sufficient to note that Apple does something enough to end an argument? Well they do Display Postscript (ok, they had to modernize the terminology to Display PDF) on OS X so obviously the idea is still mainstream, right?
Is it good that Linux is finally getting the last chunk of device support and taking over mode setting and general driving of the video hardware? Of course. Is it good that makes it easier for upstarts to experiment with new display systems? Of course! Might this someday lead to replacement for X? Perhaps. But any replacement has to be able to do the things X does if the target is a general computing environment instead of embedded. We have decades of existing apps and little desire to toss em all and start over. If we wanted to do that we could all just ditch the whole stack and go run Haiku or something.
LPC: Life after X Posted Nov 11, 2010 10:09 UTC (Thu) by dgm (subscriber, #49227) [Link]
> The question is, build what's needed by WHOM?
By us, of course! I'm sorry, because I'm going to introduce a little bit of FUD, but I think it's a healthy dose:
The problem is not that we are not well served by what we currently have. The problem is that most computer users out there are not. And as a consequence those people select other operating systems. Why should we care? Because marginal platforms can only survive thus far. Yes, there are still people writing code for the C64 and the Amiga, but they are few and mostly irrelevant, except for themselves. Do you want to see Linux there? I certainly don't.
So, It's OUR need to appeal to as many users as we can, and serve them well in as many use cases as we can, to ensure our own survival. Specialization and immobilism will be death for the platform.
|
|||||||||||||