| |||||||||||||
LPC: Life after XLPC: Life after XPosted Nov 6, 2010 20:09 UTC (Sat) by dskoll (subscriber, #1630)In reply to: LPC: Life after X by drag Parent article: LPC: Life after X
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...
(Log in to post comments)
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?
|
|||||||||||||