Slashdot Mirror
Frontiers: A New Xlib Compatible Window System
alucard writes "The JourneyOS people have published this overview of their upcoming window system. It looks like it is OpenGL based and uses XML as the communications protocol. The biggest news is that it is supposed to have Xlib compatibility, but uses HyperQueues instead of Unix domain sockets. Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility? I think this is something everyone wants, but projects to create alternative GUIs such as Fresco and PicoGUI have given up any hope of compatibility with X11 or Xlib. Can we expect another alternative out there soon?"
This will be SLOWER than X, for god's sake, at least locally. Unix domain sockets are zero-copy on Linux! XML requires full-blown parsing, X messages are fixed binary format.
Yeah sure. in THEORY, the server-client overhead of X slows it down. I have, however, yet to notice it. Hell, I get a Higher framerate with Quake3 in Linux than in win32.
To take the quake3 thing a bit further- one day I was setting up a quake3 server on a remote machine. However instead of running q3ded (the server), I ran quake3.x86 (the client) by mistake.
Imagine my horror when the screen goes blank and I realise what I have done, and SURELY, this would fsck both boxes. Theres no way quake3 can X over a 100mbit network link (with the overhead of SSH thrown in). Or can it?
A few seconds later up pops the menu. It ran fine. As a quick experiment, I loaded q3dm17. It worked, and I was getting a good 15fps- quite playable.
Dont believe me? try it for yourself.
I think that little demo alone is enough of a demonstration. X my have it's flaws- namely bloatedness, but it CERTAINLY doesn't seem slow to me.
I agree. I'm far from convinced that sockets have anything to do with X being slow. In any case, doesn't X have a shared memory option?
The point is, let's see some benchmarks PROVING that sockets slow things up before going off at some tangent to replace them.
But even if it were plain old text XML, it still poses some real advantages, not least of which you could transport it over SSL, web proxies and other barriers that would stop an X-session cold.
Besides which the transport is probably not as important as the data you are send. If the schema had sophisticated drawing primitives ala SVG you might find it is considerably faster than X which might be forced to move bitmap data around for similar operations.
The "slowdown" of optimizations for X is not a result of the protocol, but of the complexity of the task. Look at all the alternative GUI's available for Linux, and take a look at the number of drivers they support and the feature set - most of them are highly specialized because the amount of work that needs to go into a general purpose GUI system to make it useful is simply staggering, and few people have the skills to do it well.
Extending the X protocol is the easy, almost trivial, bit.
Why is it doubtful that the kernel comes into play?
You have no idea how much of a difference it makes (I'm not saying this to be derogatory, just expressing a point).
A well configured kernel provides so much more usability, some examples of things to look into:
- Anticapritory I/O Schedualer. -- Some disk read operations actually take multiple reads which get schedualed in a weird way when theres currently something being written to disk. The reads get schedualed in a way that the writes are between reads, causing the original read operation to take a lot longer due to the added latency. This patch will anticipate such situations, and cause each read to pause for a few msecs so that the next read can be schedualed instantly.
- Interactive patches (preempt, ll, et al) -- Guess if an application is interactive based on how long it sleeps between reads. An app that constantly reads is probably not interactive, so it should have less priority. You know what they say, the slowest part of a program is the user, and that is kind of how this works. When a program sleeps for input between read its marked as interactive. This way bash responds with quickness, but gcc can wait for your interactive procceses.
- IP QoS -- Not really X related, but really makes a huge performance diference. With QoS enabled, You can set it up so that small packets (500), then limit your outstream to a little less than your max so that SYN|ACKS can still get out. The result is that you can max your upload/download to your hearts content, but your latency NEVER takes a hit. I can even scp to my server while sshed in (both using the same sshd, which is why packet size comes in) and my ssh session still remains responsive.
There are more, But these are just a few examples. I'm debating writing a paper on properly setting up a modern Linux system for maximum usability, as theres a huge difference and a lot of it is in the kernel.
Sorry for any bad formatting, ironicly enough I typed this in lynx due to a few bad apps(python + wxwindows is the kiss of death, both soulseek and bittorrent tend to trash my usability). Still need to address that, heh.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Many functions run unaccelerated on cards that have all kinds of cool acceleration features... Are you aware that gtk pushes everything as a bitmap through the X protocol for each expose event?
Thank You. No one knows that; or seems to care. I'm currently playing around with a P200 with an S3 Trio64 that gives better (single pixel) Xperf results with the VESA driver than with the (accelerated?) S3 driver. KDE seems to run faster with the unaccelerated driver, which is completely unexpected.
XFree has little to no information on problems like this because they discourage discussion of performance to avoid playing favorites among video card manufacturers. There needs to be someplace that Joe User can go to get realistic advice on graphics performance in Linux, something besides the usual "buy an ATI/nVidia" spiel.
I think it's a good thing that these type of articles get posted once a week because someone needs to start talking about this; it is a serious problem that most noobs think graphics performance on Linux sucks and everyone just tells them that it doesn't or that they should use something other than KDE/Gnome. It seems that graphics and, by extension, gaming are the only areas left to hinder Linux from widespread desktop adoption by the average Windows user.
"I assumed blithely that there were no elves out there in the darkness"