Frontiers: A New Xlib Compatible Window System 439
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?"
bah. (Score:3, Interesting)
X speed really isn't an issue (Score:1, Interesting)
If you need a fast graphic system, stick with OSX (Macs are much better built from the inside than PCs, anyway) or Windows. Servers don't need X support at all (one more place to be exploited) and most workstations do fine with XFree. Live with it.
There are other points to cover. The shell, binutils, textutils (sed, awk, perl, egrep, etc) are tremendously powerfull tools. Yet there aren't that many experts around. Read a good book on that and leave fast graphics to windows.
There's an example I like to use regarding the issue. In world war II Germany, the very first jet engines were built. A German fighter could have easily won the war over Britain and delay Normandy for years, as it was significantly faster than anything else out there. The trouble was Hitler ordered to make a bomber out of it. The end result was that the decision was overturned just in time for Germany to loose the war. Considering the US will never make a bomber out of F-22, just why would you wish to add windows features to linux? Why favour speed to stability? Isn't that the very reason you took up linux in the first place?
But I don't mean any disrespect to the hard-working developers of the project. I just mean this may not be the solution to be deployed in the masses.
-i
try Quake3 over X- THEN tell me X sucks. (Score:5, Interesting)
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.
X not slow (Score:1, Interesting)
Re:X using sockets.. (Score:4, Interesting)
The point is, let's see some benchmarks PROVING that sockets slow things up before going off at some tangent to replace them.
Re:Don't think so... (Score:1, Interesting)
And as such doesn't take advantage of technology present today.
I could forsee this becoming a "desktop X" and the original X11 being a "Server X" of sorts.
Just my $0.02
XML and Speed? (Score:1, Interesting)
"Could this get rid of the speed problems"
Excuse me, XML is a text format, XLib last time I looked was a "binary" format. How in the world could XML ever be "faster" ??
I know X took alot of memory and was realy slow on my onld 386/486. But I havent notis _any_ problems with X on my Pentium, and that machine is old today to.
Its not X thats slow, its the drivers for the diffrent graphiccards that just isnt as good as the Windows counterparts.
WBXML (Score:5, Interesting)
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.
right on! (Score:3, Interesting)
One unexpected benifit of switching was the increase in the speed with which I can use it. I just spin my mouse wheel, and I'm on another desktop or a window has been (un)shaded. There is no slow config app, I can do everything from the menus.
Getting people to switch from one windowing system to another is not easy. Apple accomplished it by providing usable, if lousy, backward compatibility and a complete OS change. Microsoft accomplished it by half-ass backward compatibility that was dropped within a few years. None of the window managers will take the lead if they don't provide network transparency(why X rules), virtual terminals(Aqua doesn't respect them), a wide variety of possible window managers (I'm not leaving OpenBox), and a healthy supply of visible advantages (more than just eyecandy) and new applications.
I really think that X can be extended to what we want. Maybe someone should draft another revision of the protocol. There's no reason to start from scratch, and it's a waste to do so in the hopeless attempt to avoid bloated libraries and gain an alpha channel.
That's the Beauty of OSS (Score:2, Interesting)
BTW I am glad there are people thinking about how to continually make the old better, maybe they will fail, but plenty will be learned.
Re:could it be... (Score:3, Interesting)
Modding me troll doesn't change that fact. 2.6 might
Re:X using sockets.. (Score:2, Interesting)
There are no details about the benchmark on their page. A typical error is that the data isn't actually accessed on the receiving side. This may sound harmless, but it actually turns the results upside down due to cache issues.
Re:Microsoft owns all patents for OpenGL (Score:2, Interesting)
Re:Oh. my. god. (Score:5, Interesting)
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.
Re:ARGGH! X isn't where the slowdown is! (Score:3, Interesting)
I wish X was just a _little_ bit smarter with the copy and paste support and included a mimetype tag with the data in the cut buffer. That way your program could examine the mimetype to figure out how to handle the data. It would even be possible to transition by just adding a new function that specifies the mimetype in the cut buffer functions, if not specified (old application) assume text/plain. The X consortium moves soo slow though that I doubt I'll see anything like that anytime soon.
Re:ARGGH! X isn't where the slowdown is! (Score:3, Interesting)
- either KDE and Gnome are both slow
- or X itself is not well adaptated to modern needs, so we could say that X is slow.
Check out XFce [xfce.org] and you'll see that both KDE and Gnome are the bottleneck. It is definately possible to have a modern, sharp looking desktop that's easy on the memory and XFce provides this for me. It's very snappy on my p233 96 MB RAM laptop and uses GTK2 (the same toolkit Gnome uses). I've heard people with far slower boxes than mine say that XFce is snappy on their machines too.
Re:ARGGH! X isn't where the slowdown is! (Score:4, Interesting)
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.
Re:ARGGH! X isn't where the slowdown is! (Score:3, Interesting)
If you have issues with the performance of your linux desktop you should be looking at the applications, desktop environments, and toolkits...
Indirectly, though, isnt' that what these guys are proposing to do? Redesigning the lowest layer so that the upper layers don't have to be the way that they are now?
Cheap graphics cards are so much more capable these days than what they were back when X was designed. OpenGL support (or DirectX, whatever you want to call your hardware acceleration) is more common and less expensive than in the mid 1980's. Getting graphics cards to handle more sophisticated 2D vector operations, if it's possible, should permit the lowest level of the API to be properly designed for it. Maybe then we wouldn't suffer all these layers of abstraction and interfaces that cause people to complain of sloth and bloat.
I've used X for a long time and really like its stability and that it's a standard.
The network client-server model is a nice idea, but could use a redesign to make it more useful for higher level operations (old X terminals didn't do OpenGL) and the idea of a secure, standardized kvm services over IP is still a great idea, especially if the underlying protocol makes better use of modern graphics hardware.
I applaud the JourneyOS folks for daring to rethink the low layers of graphics. At the same time, I'd be scared that sloppy design and programming of a more complicated lower leel graphics model (especially with kernel interfaces) could lead to greater instability than I see with X (look at what happens to other OS).
And I have doubts as to how the latency and bandwidth of WXML will scale.
Until it is known whether these fears are founded or not, I still have standard X.
There's room for improvement in X. Now if only Quartz were opened up...
Re:Why I am tired of this "let's replace X" s& (Score:4, Interesting)
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.