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

could it be...

[SuperBanana]

Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility?

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.

Didn't Apple teach us anything?

[daBass]

"This allows for one of the goals of JourneyOS, which is eventual Win32 compatibility"
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.

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:That depends...

[Anonymous Coward]

Regardless of what computer you run it on, you had better count on the flying pigs being there before a window system based on OpenGL and XML beats X11. After all, despite all the slagging it gets on slashdot, X11 does have a reasonably sane binary wire protocol and XFree86 does utilize most of the 2D capabilities of your video card.

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.

Re:Hrmm

[digitalunity]

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

ARGGH! X isn't where the slowdown is!

[MarcQuadra]

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

try Quake3 over X- THEN tell me X sucks.

[SlightOverdose]

Yeah sure. in THEORY, the server-client overhead of X slows it down. I have, however, yet to notice it. Hell, I get a Higher framerate with Quake3 in Linux than in win32.

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.

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.

WBXML

[DrXym]

WBXML compresses XML down to bytecodes. It's used in WAP and other places. It works off the DTD, assigning bytes to represent the various tags and attributes.

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.

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