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?"
nobody seems to have read the project page yet, or you'd note that the 'journeyOS people' are exactly one, the 'founder', and that so far the product is a conceptual description of an OS and another of a GUI. yep, that's it, no programmers, no code.
not that i think noble adventures dont start small, but if the tons of smart people working on wine cant keep full compatibility, and the xfree86 team is having trouble getting substantial performance improvements....well, i wish this guy luck.
sure sometimes we need a fresh start, but it seems as though journeyOS has perhaps a little more ambition than is healthy (posix and win32 compatibility, in full, and with good performance), and little in the way of resources. perhaps he could ask hans reiser about just how hard it is to design a good FS?
seems to have bitten off more than he could chew, and as another poster has already noted, may have made some bad strategic choices at the same time. why xml for screen drawing when metadata is so often repeated? why design the GUI for the libOS that doesnt have any programs supported, rather than those that do (ie, POSIX, win32)?
perhaps all in all 'dream big' would be a better motto for them...
U.S. War Crimes blog. Email for free Mandriva support.
OK, repeat after me... X is NOT SLOW BECAUSE IT USES SOCKETS!!! Please understand this! When you are on a local machine it uses optimised sockets, which are the fastest way of streaming information between programs, and were designed into linux for that specific purpose. Also.. you say "Speed up".. and they are going to use XML?? Sending information via a bloated ASCII (or even unicode)-based protocol? Yep, that will be fast won't it.. espically if they parse all the XML they recieve to make sure it is correct.. *sigh*
Combination - fun iPhone puzzling
a binary protocol should be used. :-)
A binary protocol is being used: it's WBXML over HyperQueue. RTFA.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Before everybody and their mothers starts flaming them because they use XML as their protocol, I would like to point out that they are using WBXML to send their messages.
WBXML is a packed encoding for XML, thus saving space and all those that can be highly compressed. Just have a look at the specs, it's not because it has WAP tagged to it that it's a load of crap.
And then, to those saying that the parser will kill the perfs, I'd like to point out that this protocol doesn't rely on string parsing but _byte_ parsing..
The messages aren't in textual XML format, they're in WBXML, which isn't going to require nearly as much work in parsing etc. (Whether you consider WBXML messages to be "fixed binary format" or not is up to you.)
Jon
> Same hardware, same system: Windows is smooth, Linux GUI is choppy. That has been repeated over and over again.
Running FreeBSD 4.8 with XFree 4.3 on a dual pII 333 witth nvidia geforce4 here.. Have an exactly identical machine running Windows2k (oh, machine has 512mb ram(
Comparing the 2 gives a very simple result, XFree beats windows on each and every area when it comes to graphcs performance on that hardware.
Window movement is more smooth, resizing windows is smoother as well. I can run the Linux versions of games like Quake 3, Enemy Territory etc on FreeBSD and they are very well playable, while the same is simply nogo on Windows..
The only way ion which things are repeated over and over regardign this is in people repeating over and over the same utter bullshit statement as you did.
KDE takes 20 seconds to start up and each application takes a couple of seconds to load.
Prelinking the libraries and applications is supposed to help in this area. See the Gentoo guide to prelinking for more details.
The article mentioned a couple interesting advantages of XML. The client/server communication stream can be validated in realtime by an XML parser, greatly reducing debugging time. They also state that they can later switch from XML on the wire, to ASN.1. Their XML schema can be mapped to ASN.1 which has much lower bandwidth and computational requirements.
NOT TRUE AT ALL.
;-)
OpenGL is just an API. If your app sticks with 2D calls, you should be fine even on graphics chips that only support 2D. Simply implement a basic 2D path in your OpenGL driver and punt the rest to software. My hourly rate is reasonable if you're interested
Dudes, somebody just took the overview of the window system and threw it through something like DadaDodo. Mod it down.
Now, Quake3 can be expected to have a rather advanced renderer that pushes as little stuff as possible to the graphics card, so it's not such a big surprise that it can do with one hundred megabits. The bandwidth of AGP 1x is 266 megabytes per second, which does put the network one magnitude lower, but then again if you can get 10fps over the network where you can get 100fps locally, the values are in the ballpark.
I've sort-of tried this with Half-life, but the client side ran Wine between HL itself and the network (which might cause a lot of overhead outside - or then not, I can't tell) and the server side had an old ISA network card, so I got at best something like one frame per second in the hazard course. 15 fps on much better hardware is, IMO, conceivable and credible.
Do you ever read sources?
... Meta-information, including the document type definition and conditional sections, is removed when the document is converted to the binary format.
That might help, but you're still shipping a lot of redundant metadata around.
From the WBXML specification abstract:
Not if you want to remain fully compatible with existing XLib code.
What? They provide a library that is xlib compatible and then extend it with more drawing primitives. What it makes xlib-incompatible is applications that use that specific primitives with plain X. xlib applications are not affected.
It seems you dismissed the whole thing just after reading the post and you are just justifying that without checking other's arguments...