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

Comments

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

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