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?"

total vaporware

[rmm4pi8]

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...

X using sockets..

[Chris_Jefferson]

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*

Re:XML

[hummassa]

a binary protocol should be used.
A binary protocol is being used: it's WBXML over HyperQueue. RTFA. :-)

Hold on cowboy!

[palad1]

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 [w3.org] 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..

Re:bah.

[Westley]

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

Re:X using sockets..

[Anonymous Coward]

No, despite you use optimized socket, for every pixel you want to draw,
you still need to do context switch, one from your program to X server,
and then X server switch back to your program, then performance is lost,
if you have lots of pixesl want to draw, performance is reduced dramatically
despite how fast linux can do in context switch.
This is why Win32 is faster then X11, Win32 does not have such issu.e

Re:could it be...

[Anonymous Coward]

> 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.

Re:How about speeding up the GUI, like KDE?

[Elbelow]

KDE takes 20 seconds to start up and each application takes a couple of seconds to load.

Prelinking [freshmeat.net] the libraries and applications is supposed to help in this area. See the Gentoo guide to prelinking [gentoo.org] for more details.

Re:bah.

[Anonymous Coward]

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.

Re:Hrmm

[Stiletto]

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 ;-)

Re:That depends...

[ActiveSX]

Dudes, somebody just took the overview [sourceforge.net] of the window system and threw it through something like DadaDodo [jwz.org]. Mod it down.

Re:try Quake3 over X- THEN tell me X sucks.

[Ari Rahikkala]

X is not concerned with 3D stuffs except for the initialisation of the GL context.

As soon as the app has its own GL context, it directly talks to the hardware. X has nothing to do with this business except in the forwarding of events (mouse, keyboard). Only the driver, the app and the 3D card play a role in this case.

The parent was running Quake3 remotely over X. This means that the client talks to the server in GLX (OpenGL encoded in X11 packets [opengl.org]). What you're describing is DRI, which can be used only locally.

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.

Re:WBXML

[luisdom]

Do you ever read sources?

That might help, but you're still shipping a lot of redundant metadata around.
From the WBXML specification abstract: ... Meta-information, including the document type definition and conditional sections, is removed when the document is converted to the binary format.

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...