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?"
XML is a good choice for storing data when you might want to extend the attributes of a record/properties of an object without breaking existing applications. That's inherent to the design of XML - so long as you query your documents in a structured way - say with a DOM parser and XPath - then "extra" tags don't make a blind bit of difference, except for taking up some memory and some processor time.
But it's an extremely bad choice if you want to move lots of the same type of data around, when you know the format of the data in advance, and you do if what you're sending is drawing primitives, GUI widgets from a standard toolkit, etc etc. That is because of all the redundant metadata. If you are sending (for example) a CSV file the metadata comes once, in the header, and all the rest is pure data. An XML file stores the structure with the data - if you did this in a CSV file, it would mean repeating the header every other line, doubling the size if your file (or stream) for no advantage. It's worse with XML where you might have <somelongtagname>1</somelongtagname> - that is, your metada being far larger than your data. All compression does is add both processor and memory overhead at both ends, assuming the network isn't already saturated.
I know that XML is "trendy" but it's the wrong tool here - a binary protocol should be used.
Could it be that the poster hasn't read more than 1 page into the comments on the last dozen times this X-is-slow BS has come up? I thought we all agreed on this one, but apparently not.
This is very frustrating to see, because this makes for system #3, and things were already bad enough with 5 billion different window managers. Choice is great and all, but there's a reason some things are standardized, and "xlib compatibility" is not the same as "X"; I guarantee this new system will break all sorts of things in new and exciting ways.
Perfect example of how open-source has failed us; EVERYBODY's gotta invent their own wheel instead of helping to make the existing wheel(s) better.
Please help metamoderate.
Oh no. Not just X, but also Win32 compatible.
I doubt we'll ever see this project finish. When is anybody going to just start from scratch, like Apple did with OS X? Build it and they will come.
Of course XFree86 depends on the card manufacturers giving them documentation for the hardware, but if the manufacturer doesn't see any advantage in helping Linux use their cards to their fullest, don't expect for a minute that they would help some unknown group like JourneyOS.
The idea here isn't to create an X alternative, but an X replacement. Something modern, fast, light. I know everyone is going to chime in with 'XFree86 is good enough. And it isn't bloated or slow'. It is an excellent piece of software, but it isn't as fast as it could be. There are commercial X11 servers for Linux that really are as fast as advertised, I've seen it in person. Another of the 'problems' with XFree86, and even commercial X11 servers is that they don't take advantage of modern GPU's. Granted, OpenGL isn't an ideal method of rendering *everything*, but for some things, it would offload much of the graphics subsystem from the CPU. There are cases where OpenGL would be much slower, but with a little smart programming, this can be avoided. OpenGL also has the added benefit of adding some eye-candy features like transparency without taxing the CPU. Anti-aliased vector fonts are easy with OpenGL.
The only problem I see here, besides the usage of XML(it's flexible and easy to program, but too large as a metadata medium), is that many have tried this before and failed. Only time will tell.
I'll give it a week before declaring it 'YetAnotherDOA sourceforge project'.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Alright, people need to listen closely. XFree86 is NOT SLOW, the toolkits you lay on top of it are what bogs it down.
I get full-window dragging and resizing in WindowMaker on my old 366MHz laptop, and it has an ATI Mach64 video chipset. Windows crawls when I do similar operations on the same hardware.
I seriously suggest that if you think X is slow you check out a more lightweight window manager and apps. GNOME and KDE have a LOT of overhead because they run on top of an extra layer of abstraction (GTK+ and QT, respectively). WindowMaker is written in C to interface with X more directly and it shows.
You can still use your GNOME/KDE apps under WindowMaker, I'm using konqueror as my file manager right now. Try it.
As for this project, it sounds cool to me. I think X is plenty fast as it is, but that doesn't mean I think someone should take what we've learned over the last decade and apply it to a more modern 'ground-up' solution. It would be nice if there was an X replacement that had QT and/or GTK+ tied in more closely, or if we had a quartz-extreme-like OpenGL windowing system and font renderer with postscript-esque qualities (i.e. run my desktop at high resolution, but zoom everything appropriately for 'real-world' DPI).
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I used to run ratpoison. As others have already pointed, X is actually very fast, the problem are the toolkits. It's nice to have alternatives, but IMHO toolkit optimization is much more urgent.
Today I'm using Gnome. It's beautiful and useful, but the feature that hooked me was the superb i18n support (now I can finally do with X11 apps what I always did with Emacs: switch the input method! No more restarting apps to write multilingual Japanese/Portuguese texts!). But it is not fast, and that's in a Duron 800, 128Mb RAM. Gnome can be great for the third world, where we still have lots of Pentium 100s hanging around. Gnome and KDE are both excellent desktops, but they need speedups.
The main problem with X is (still) video card support and configuration (ever played with Trident TGUIs 9680? I have an LTSP net full of them). There's a lot of work to do, but we have come very far in this aspect. I doubt a "modern window system" wannabe could easily offer similar support.
Prescriptive grammar:linguistics