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?"
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
I don't see how encoding/parsing a bunch of XML code, and adding a xlib wrapping layer is going to improve the "slowness of xfree86". If XFree86 is slow, it is most probably the fault of the toolkits and apps. X itself isn't slow, it was designed for far slower machines than todays PCs remember?
This will be SLOWER than X, for god's sake, at least locally. Unix domain sockets are zero-copy on Linux! XML requires full-blown parsing, X messages are fixed binary format.
I can't see how creating more X alternatives or derivatives are going to help linux become more mainstream on the desktop?
Perhaps someone could explain that to me...
Be you Admins? nay, we are but lusers!
Replacement for X. Not bloody likely.
No networking capability and difficult to port since it is tied into a x86-only features.
Anyways, remember X only uses networking IF IT HAS TO. No TCP crap if your on the same computer as the X client, it all goes thru sockets, which are plenty fast.
I wouldn't mind a replacement to X, but this isn't it.
I for one, not even going to say that, will at least try it out. If it is faster, great, if not, boo hoo. I like that there are atleast options though. Second, I havent noticed speed issues with XFree86. I seem to get the same type speed using the winblows game engines as I do the OpenGL. When else would you need speed from your graphics system. OK, well, besides graphic design (which I think is more processor and memory intensive and less dependent on the graphics engines/backends, but I could be wrong)
Stop signs are only Suggestions
XML and OpenGL? Hardly the stuff of a light, nimble system then. Check out the per-pixel shaded snowflakes on xsnow! Of course you only get 1/minute on your pentium, and thats when its finished parsing the XML that is. If I start it now, will it have rendered by Christmas?
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.
Yawn, yet another X alternative/replacement. My prediction is that 15 years from now we'll still be using X11. Probably still XFree86, even.
I do not see how ASCII code is faster than binary, but XML is into everything... I have code-named it the Borg.
How I hate Slashcode lookalikes as frontends for project homepages. You're spending hours looking to find a simple project introduction, FAQ or screenshots...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
and uses XML as the communications protocol.
Thanks, no, I never want to try this one. XML as communication protocol is a nice generalization on the paper, but in practice, it sucks. GUIs should be optimized for speed, and thus, the protocols should be specialized, too.
A monkey is doing the real work for me.
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
I suppose a gimp can run faster than Carl Lewis, but it'll take an awful lot to train him...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
The primary focus of an xfree replacement would obviously be better speed overall. It wouldn't create fragmentation of the linux desktop if it was clearly a faster alternative.
feeling lonely? grab a balled up pillow for company
Look at project Everblue... on OS/2 Netlabs. Its not exactly news since it started around 1999. (There again, Slashdot doesn't report much on non-Linux news, especially in that era)
http://everblue.netlabs.org/
It has Xlib compatibility and maps it on to the OS/2 Presentation Manager UI.
It's quite possible for someone to pick up the code and do it for their favorite UI.
-- The universe began. Life started on a billion worlds...
-- Except on one where stupidity was there first.
I doubt they are going to get speed because they are using XML and "HyperQueues". They still might, if they are using a stellar opengl implementation, who knows :)
--exa--
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
.. or at least not one of the more vital out there. The trick is most people view linux as an alternative to Windows, while it's infact a supplement. Linux is intended to be used for different things (workstation/server) than Windows (game/SOHO office machine). The mindset Unices have traditionally supported was stability in favor of features, and that shouldn't change.
If you need a fast graphic system, stick with OSX (Macs are much better built from the inside than PCs, anyway) or Windows. Servers don't need X support at all (one more place to be exploited) and most workstations do fine with XFree. Live with it.
There are other points to cover. The shell, binutils, textutils (sed, awk, perl, egrep, etc) are tremendously powerfull tools. Yet there aren't that many experts around. Read a good book on that and leave fast graphics to windows.
There's an example I like to use regarding the issue. In world war II Germany, the very first jet engines were built. A German fighter could have easily won the war over Britain and delay Normandy for years, as it was significantly faster than anything else out there. The trouble was Hitler ordered to make a bomber out of it. The end result was that the decision was overturned just in time for Germany to loose the war. Considering the US will never make a bomber out of F-22, just why would you wish to add windows features to linux? Why favour speed to stability? Isn't that the very reason you took up linux in the first place?
But I don't mean any disrespect to the hard-working developers of the project. I just mean this may not be the solution to be deployed in the masses.
-i
Its most likely vapor ware, every other day there is news about a new system to replace X, but none of them ever made it out of the tech preview stage at best, X really needs to be replaced for desktop/home based systems, for server/thin client based its OK, but its far too basic to truly support all GUI functions of windows/macos what I would like to see is something similar to how qnx works with X windows apps, ware it seems to load X in the background but displays the apps as if they are normal apps, I assume that this idea of xlibs comp. would mean that X apps can load hopefully without requiring a recompile. unfortunately at this point switching the GUI isn't feasible as it would require that video card drivers and software be made for it, and its hard enough getting hardware makers to release X drivers, much less drivers for another windowing system
I dont know xml, or how it works or parses and crap. But wouldn't moving the system calls to the client speed up the server side but bog down the client with no effective gains to the end user? I dont program and am pretty ignorant when it comes to this stuff. Looking at the other posts though, the xml will slow down the server. With the client doing even more work (system calls) to the client, wont that also slow down the who damn thing? Could someone be kind enough to explain this to me.
Stop signs are only Suggestions
So the problem now is too much speed? You need to introduce a bloated text format to slow down the framerate?
I guess to answer the question, yes all speed problems are eliminated. The graphics are all uniformly slow.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
i do not ever have problems with XFree86 it runs great for me. what usually causes problems in Linux is the big bloated desktop environments like Gnome & KDE, get rid of the bloated desktop environments and use a lighter alternative such as WindowMaker or XFce4 is nice, or ICEwm is nice too, and you will see that XFree86 is not the problem...
After listening to all the vaporous hype, I decided to go ahead and write my own, fully Xlib compatible replacement for X:
#!/bin/sh
exec xinit
I eat Xlib for breakfast! *burp*
...anything but IA32 yet...?
It used to only be faster because of some IA32 explicit advantages, otherwise HyperQueues is the same as another messaging method.
Loading...
this is NOT something everybody wants. reasons are: OpenGL is displayed in overlay. thus you can not use it network transparant. XML is very bloated. and last but not least: i doubt that with an additional layer this Xlib is going to be much faster. (it is still limited to its design.)
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
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.
X is NOT slow. XFree86 may leave something to be desired, but if you whip out Xi Graphics' X server and take it for a spin, you'd be shocked at the difference in performance. Xi hasn't implemented all of the bells and whistles of XFree86 (actually, they've implemented different bells and whistles), but it clearly demonstrates that, under Linux at least, X can perform exceptionally well.
According to the website "exotic features of modern X servers such as the MIT shared memory extension, Xrender, Xv, and others will not be supported". Xrender and Xv are really needed if you would want me to switch. otherwise you still have to fall back on software rendering all the time. ( and thus this window manager will still be as slow as hell )
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..
Can we expect another alternative out there soon?
Judging from the success of all the other zillion "I'm gonna create something new which will replace X"-projects, I suspect not.
report on every bit of Vaporware that emerges? Ideas for replacements for X are nice, and I appreciate the efforts to improve *nix in any way. But I's rather hear about something with a bit of 'meat' to it instead of yet another pipe dream. Maybe we need a Slashdot forum where we are able to post daily thoughts that cross our minds that others may be able to use to spark ideas for new and better applications/OS's, etc...
-Cnik
"uses XML as the communications protocol"
"Could this get rid of the speed problems"
Excuse me, XML is a text format, XLib last time I looked was a "binary" format. How in the world could XML ever be "faster" ??
I know X took alot of memory and was realy slow on my onld 386/486. But I havent notis _any_ problems with X on my Pentium, and that machine is old today to.
Its not X thats slow, its the drivers for the diffrent graphiccards that just isnt as good as the Windows counterparts.
At least if an OSS project fails the code is available for other projects to scavenge and incorporate. Where's all that closed-source code written for the dot.coms now? It's GONE or in the hands of lawyers, it will do no good for anyone.
OSS is great because it can pull in a thousand directions at once and still end up at the destination.
Mozilla is a great example, the core application has been extended to include a bazillion features, but its actually a kickass suite. And now there's a layout engine (gecko) that can be used in other applications to provide kickass HTML support.
GNOME and KDE are another great example, the rivalry has done more to further the project than anything else. Windows has come a LOT less far in the same time that KDE and GNOME have been around.
Could we move faster if there weren't competition, sure, but we'd need a lot of MONEY and MANAGERS to keep everyone in line and on-task. Luckily we don't have the burden of pandering for money or slaving under managers to get what we want.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
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.
My biggest speed problem on X at the moment is the startup times etc of applications. KDE takes 20 seconds to start up and each application takes a couple of seconds to load. Could this be sped up by a faster X server? Or is the problem there more likely Qt, KDE libs, etc?
...but a *proposal* for a whole new OS, indeed.
Everything he says is beautiful. Exokernels aren't BS or pixie dust, they're just a way of saying 'all functionality lives in libraries.' Having functionality in modular libraries means you can add/replace them as you choose, conceivably making development easier and the user experience more pleasant. (No need to build device driver modules against a kernel version, hopefully "libOS" interfaces are better thought out and change less often. Beauty is that filesystems and *everything else* become equally modular, and you can conceivably support as many different wholly unrelated APIs/ABIs as you want, at once, though the more you throw in, the more it does look like any regular machine running a few copies of VMWare... but still, with less of a performance hit.)
Seriously, let's not be down on it. It's beautiful, *if* they can pull it off. The windowing system architecture is "smart" given today's standards, if nothing shocking. I doubt there will be *major* performance gains or losses versus X, but some people might prefer the native API as the 'fresh start' you want.
In the end, these designs give us back the flexibility that... gasp, horror... the Commodore Amiga had 20 years ago. The difference is that the Amiga/MetaComCo guys didn't *have* to invent 'HyperQueues' or other mechanisms for protected message passing; as an '80s-era personal computer, the Amiga just didn't have protected memory at all.
...being one of the current software fashions? This would be a point in that case I guess.
Mind you, XML is good. Especially because it's such an extremely picky data format. It's the only way to go for flexible document formats and all that, imho. But XML to shove grafics around a 2D space?
Come on, give me a break.
No, guys, nice try, but that guy with his XFree replacement called 'Y' a few days ago was much more promising.
Next.
We suffer more in our imagination than in reality. - Seneca
Is XLib compatibilty really an issue? How much software is written in native XLib these days? Isn't compatibility with the various widget sets what we really need in a X replacement?
They plan to use WBXML and not XML. Still you need parsing. But serialization can be left out AFAIR. That's a huge improvement over Ascii XML.
But still it is an extensible format.
And they are looking into ways to move to ASN.1 too. See the link in the article.
I don't think that Journey is the best band to name a piece of software after. Just look at the precedent.
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
For once, this guy is trying to do a GOOD open source project. He is starting form the ground up with design documents, sepc'ing everything he wants out before he starts coding.
Projects that are designed properly from the beginning and stick to that design while coding are normally more robust, and the actual coding is quicker since you already solved a large number of potential difficulties during the planning phase.
I use OpenBox, also a slimmed down GUI.
One unexpected benifit of switching was the increase in the speed with which I can use it. I just spin my mouse wheel, and I'm on another desktop or a window has been (un)shaded. There is no slow config app, I can do everything from the menus.
Getting people to switch from one windowing system to another is not easy. Apple accomplished it by providing usable, if lousy, backward compatibility and a complete OS change. Microsoft accomplished it by half-ass backward compatibility that was dropped within a few years. None of the window managers will take the lead if they don't provide network transparency(why X rules), virtual terminals(Aqua doesn't respect them), a wide variety of possible window managers (I'm not leaving OpenBox), and a healthy supply of visible advantages (more than just eyecandy) and new applications.
I really think that X can be extended to what we want. Maybe someone should draft another revision of the protocol. There's no reason to start from scratch, and it's a waste to do so in the hopeless attempt to avoid bloated libraries and gain an alpha channel.
You can't judge a book by the way it wears its hair.
You see some of us don't care about extending what's out there. Some of us do. The great thing is that we are all free to move and create as we please. Sometimes it is done for the greater good of the community sometimes it is for our own selfish reasons. Perhaps you should quit assuming that we sit up late hours pounding out code to fit in with some master plan you or others have.
BTW I am glad there are people thinking about how to continually make the old better, maybe they will fail, but plenty will be learned.
what?
Forget about xlib compatibility for a moment. This is not just some software wrapper implementing xlib on top of some crackpot graphics interface (while this is tedious and time consuming work, it can be done by any programmer).
This is someone fusing the microkernel and exokernel concepts, which is way more exciting than fusing some implementation stuff together. This is actually computer science research what this man is doing, not just code hacking. I wish the man all the best for his work, for new directions in operating systems research are sorely needed, and exokernels are a particularly interesting concept (the exokernel inventors at MIT showed some really incredible performance gains, but their exokernel implementation was never aspiring to be a general purpose OS like this project).
I will try to monitor this project and maybe even help a little.
I recall reading last year that SGI sold ownership of OpenGL patents to Microsoft. SGI was open with OpenGL; therefore, it became a de facto standard like JPEG and GIF image formats.
Could Microsoft, however, use ownership of these patents at will to demand royalties from products (i.e GPUs) that implement OpenGL?
How would OpenGL based applications like this be affected if Microsoft opted to SCOnicate OpenGL? Basing anything on OpenGL could be playing with fire.
Did they decide to use XML because it has X in the name?
One line blog. I hear that they're called Twitters now.
I've had foirst hand experience with a couple of those commercial Xservers when trying to get a wildcat card to work under Linux.
.
Big fun, not.
It was expensive (mainly the card, which cost over $2000) and slow and required linking with different libGLs.
Doing the same with XF86 and an nvidia card (geforce 4 series) we got
- better performance
- much cheaper
- no relinking necesary (the nvidia libGL.so can be plugged inplace of the mesa ones and will work).
I've tried another (commercial) xserver on an older gateway laptop with ATI rage mobility card.
One again it was an act of frustration comparable to my early days of XF4.0.0 (or actually 3.99.99) where you basically had to craft an entire XF86Config file by hand and pray it would work.
When I finally had evrything up and runnign the 2D was slower (although only slightly) and the Xserver was simply not stable.
The experimantal DRI patches for the 8M mobility were about as stable (cannot remember which one had a better framerate, but both allowed me to play quake3
Having said all that though, this sounds like something really prmising, but unless they can get this towork on the latest geenration of GPUs (nvidia, ati, matrox) this will never take off.
And of course, it would need to be network transparent, so that you can still run xbiff on your solaris box and have it display onyour linux X-screen
REOSpeedwagOS?
craft an entire config file? By hand? No freakin way. That's absurd.
At what point did Linux start being used by people who wanted everything done for them? I don't want an OS that is configurable by the mainstream. Usable? Sure, what the hell. Don't care. Configurable? Not if they don't want to learn how to do a few things...
What kind of dumbasses submit these articles?
XML is not a protocol! XML is a method of formatting structured text data. In this case the protocol seems to be HyperQueue (whetever that is) and the payload is formatted in XML (and compressed).
Using XML instead of a streamlined binary format and then compressing it to save bandwidth is double stupid.
Antti S. Brax - Old school - http://www.iki.fi/asb/
everything is a socket. Its things that aren't that cause problems. Its supposed to be such. Its intended that way.
That, and as has been pointed out - there are indeed fast commercial XF86 systems (so we know its possible...). What X needs is not a replacement, but a restructuring and attunement. You need the option of something built ground-up with GL support, and as an alternative (for the lil pda or whatever) something that isn't - have your happy little gui install determine ask you which you would prefer.
Then the community needs to not write things that don't need the GL specifically for the GL version, and instead make it work on both. Only those things (games, video editing or viewing of any sort, etc) that need it should make use of the differences in libraries and such.
Dude, the protocol is XML based. This is not a way to make anything - other than development time - faster.
Here is a crude diagram of how Qt works.GTK works like this.Athena works like thisAs you can see, Qt and athena have less abstraction layers to go through, and that makes it run a lot faster. Anyone who has used konqueror recently (kde cvs or 3.2 alpha) will love the speed. Heres why its much faster
MozillaKonquerorThe reason why konqueror is much faster is because it uses native qt calls rather than a kludgy language called XUL which needs to be parsed and converted into GTK calls which goes through the usual slowdown! Thats why apple uses KHTML technology in its browser, no need to bog your new G5 with mozilla!
X is not slow, just run a app through a tracing tool and see how many library calls GTK apps make compared to KDE apps, its insane!
Hence because GTK is so slow, the gnome team had to strip their apps (read : remove features) to compensate for it.
Why do the lame-assed UI crowd keep posting about these lame-assed UI/GUI's that don't stand a ghost of a chance of ever being adopted? Could it be that they think that the Linux/BSD/Open Source/Free Software cummunity is actually *STUPID* enough to work on their lame-assed ideas just so the UI crowd can come along later and claim all the credit for work they never did? Sure as hell sounds like it.
Which speed problem? I've been working over ssh-tunneled remote X connections without even noticing.
All these "X sucks, we're gonna make something better" projects bore me. We've had them at a rate of about 1 per year. So far, none of them have produced anything worth a 2nd look.
Call back when you have a tech demo.
Assorted stuff I do sometimes: Lemuria.org
The 2x speed up was comparing to sockets and sysv message queues alone. It's possible, especially if you are avoiding syscalls and the sysv message queue implementation is particularly inept. But it depends on what the overall percentage of overhead is attributable to queueing vs. rendering. If queueing is only 4% of overhead, then a 2x improvement is only going to be a 2% performance improvement. Maybe if they really are writing to X pixel by pixel.
it's a shame that everyone always get all up tight over replacements for X and Xfree86. i use Xfree86. it does what i need, and is more than fast enough for what i do(3D graphics). even still, if some one wants to come up with an alternative, Great!
if they can make it compatable with the tools i already use, Even Better!
I'll try it.
if it is an improvement, then i'll keep it.
if not, i'll go back to Xfree86. it has always served me well.
This is not the project you are looking for.
Y: A Successor to the X Window System is.
Now move along.
It's 10 PM. Do you know if you're un-American?
I wish I had more freedom to use non-shitty reinventions of the wheel. Something that OSS sadly has way too much of.
> I get full-window dragging and resizing in WindowMaker on my old 366MHz laptop
I got that on my 8Mhz RISCOS computer.. why are modern desktops so inefficient?
Google for HyperQueue. It returns one hit (pointing to the JourneyOS homepage at SourceForge), plus a suggestion that you instead search for HyperQueer (Ooookay).
(Okay, so this is one word and not two -- two being required for this to be a true Googlewhack).
Started by me.
I post this here mostly to clarify any misconceptions that folks might have about XF86. On the other hand I say bravo to anyone who can provide an alternative to XF86. We could use one. Even if this project turns out not to be "it". Personally I'm holding out for this one. And keep in mind folks, do not throw the baby out with the bathwater!
Un-news
uses XML as the communications protocol
Last I checked, XML is a markup language (like HTML) and has no associated protocol specifically designed for transporting it. Note that HTML does have an associated protocol, it's called HTTP.
I would have expected something like a 10x performance boost for something named "Hyper" Queues, rather than approximately a 2x boost. This 2x could easily by eaten up by the size of the messages, using XML messages instead of X11 protocol messages.
"X is slow"
"X is bloated"
"X is old"
"X needs to be rewritten"
Blah, blah blah, blah, blah. Blah. I'm going to be honest here, workstation performance is abysmal on any of the recent flavours of Unix, expecially gnome/KDE, and expecially XF86. There are basically two reasons for this:
1) XFree86 sucks
2) and XF86 sucks
(I am not being sarcastic - please hear me out...) Xfree86 sucks because it does not have good drivers. Many functions run unaccelerated on cards that have all kinds of cool acceleration features. It seems some of these features have been written, but not added to the tree ( or so I have been told.)
XFree86 sucks because it has not been proactive in implementing the features/extensions required by the newer toolkits like gtk+/qt. Are you aware that gtk pushes everything as a bitmap through the X protocol for each expose event? XRender is probably the only instance where the toolkits waited for an X extension to be developed before added in a feature that required it - generally the toolkit authors, rather than wait for an X extension or piece of functionality, they will implement it in the toolkit so that the client just pushes the pixels dow to the X server.
Do not look to discard X. X is in fact the one thing that we have that Windows and Mac do not have. It gives us years of backwards compatiblity, and an extensible, network transparent architecture. Instead, we should put our hopes in Xouvert and similar projects that are looking to give us a world-class X server, and the pieces that the toolkit authors need to optimize their toolkits for X.
Schrodinger's cat is either dead or really pissed off...
It was one of Microsoft's more brain dead ideas putting the GUI mostly in kernel space and then having interactions with drivers. The increased reliability is one area which I'm glad to pay for with slightly worse performance.
See my journal, I write things there
sure, and my pure-text console screems on a p66.
;-)
if GTK or Qt, both well designed toolkits, run slowly, chances are, it's *not them*. X has lots of problems forcing both of those toolkits to do a lot more work than they should need to in order to provide functionality to the user. if you bitch about apps being the problem, and to just remove the apps... what is the point of using my computer at all then?
your previous post also goes on with some more nonsense facts, like how WindowMaker being C makes it noticably faster - I hate to tell you this, but just about all of GNOME is written in C, too.
im not saying GTK/Qt/GNOME/KDE don't have problems (GTK still doesn't handle events as efficiently as it could, forcing more round trips and redraws then necessary), but they are far from the only problem.
not even your WindowMaker can do some of the things OS X and Longhorn can(will) do, simply because basic 2D acceleration with a complete lack of things like transparency isn't enough. to say XFree86 is perfectly fine and speedy is like saying your tty is perfectly fine and speedy - technically true, but completely irrelevant of what *most* people actually use their computers for.
Queueing messages in shared memory isn't new. Neither are spinlocks. Indeed, if you have done much threading on multiprocessing systems (with more than one thread active), you have probably already done this. However, a spinlock spinning is expensive.
See my journal, I write things there
How stupid can they be? Ripping off a bunch of old Journey grahpics, and record titles. Sure, the name can be used because they're not making music (at least until they bundle an mp3 player) but the album cover images on the site are certainly ripped off and should not be used. BTW, I didn't see the license. Is it GPL? We don't need another "closable source" window system. Then again, we don't need GPLed projects running around with ripped-off logos.
Just curious, using OS X today and always wanted to use NeXT back then but could never afford to.
the article states that they will be able to easily convert to ASN.1, which appears to be made for this kind of thing.
I don't know where the submittor is going saying that PicoGUI has given up on X11 compatibility -- It has a native X11 output driver with root window support! AFAIK, it calls Xlib directly.
Note that it also has an SDL driver that keeps everything inside a window, but that is simply just another output device to PicoGUI. It's not just a windowing toolkit after all...
~GoRK
That must be why jabber is so horribly slow. Completely unusable. Not.
hey, didnt everyone hear the last time i shouted that XDirectFB does X compatibility for DirectFB? all we (as in everyone using X11 right now) has to do is fuck XFree86 RIGHT NOW and start using DirectFB.
gtk2 has been ported to run nativly on DirectFB so all (most) gtk2 apps already run nativly. just all the rest of those other apps need to run in the X server (XDirectFB) till someone ports them over.
Alright, the Windows Window Manager doesn't have 'desktop icons' either, explorer.exe provides them, the file manager provides them. Don't believe me? open an app, and kill explorer.exe with the task manager, watch 'my computer' disappear.
You can certainly run an external file manager that provides desktop icons under WindowMaker, and that would be the only fair way to compare these apples.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Infinity LibOS...has what is primarily a proprietary API with some POSIX compatibility where it is sensible.
Is this just poor wording choice, or is he really trying to fork a GPL'd project and make it proprietary?
There's nothing about licensing at the linked sourceforge site, and his CVS repository is just an import of Fiasco at this point, AFAICT.
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
It seems to me that something that can 'faithfully' run xlib stuff 'any way you want it' and embrace XML with 'open arms' deserves a chance. Of course, going 'separate ways' on the Xfree86 compatibility could really put it in the 'line of fire'.
;)
My appologies, a Journey fan...
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
Since the guy is to write a totally new O/S, I advise him the following:
1) make the system full object-oriented inside-out, from kernel to applications.
2) let the system manage the inter-object communication:
a) if objects live in the same process, then they are linked together.
b) if objects live in different processes, use an interprocess communication.
c) if objects live in different machines, use an IPC communication.
All the programmer must see is a 'object.foo(param1, param2, param3)' in all applications under all circumstances(in-process, inter-process, remote).
The system will also manage security and access during object communication.
After the object mechanism is well established, it would be trivial to:
1) have GUI objects either in the same process, different processes or different machines.
2) allow users to easily reuse GUI resources (fonts, bitmaps, etc)
3) new functionality can be later implemented by simply replacing class X with subclass Y.
4) older apps can be retrofitted by replacing old class with new class of same name; the system must do class versioning.
This mechanism also extends into the non-GUI realm:
1) information as objects (with reflection!!!)
2) a consistent object model that all applications see.
3) ability for scripts to use the same objects as statically compiled code.
I think it's partially because the Windows GUI is in the kernel.
It think it's also because X is based on messaging. Even when running locally, XLib serializes gui calls into messages, sends them through a socket, then the X server parses and interprets them. That is going to slow things down.
The right way to do it is to have programs dynamically link to a different implementation of the GUI library, depending on whether they'll be running locally or remotely. Calling into the local version of the library should not construct any "messages," just a trap into protected mode when it comes time to access the hardware. If running remotely, then the gui library is a proxy which constructs and sends messages, like X.
This could all be implemented while preserving Xlib compatibility, it just wouldn't use the X wire protocol. But honestly, who constructs their own X messages instead of using XLib?
As for this idea of using XML, I think it's nuts. We've got to get "parsing" out of the equation, at least when running locally.
I mentioned in this in a prevous post last summer (/. isn't working correctly now and I can't pull up the link, so if you can browse my user posts, it's in there somewhere)
:D), so far I send enter/leave notify, button press/release, motion notify... windows default to a button grabbing mode and can pass grabs onto other windows, implimenting a popup menu system in a tk should be trivial.
So far I've got the compositing of windows down, windows are displayed hierarchicly and can be composited with any of the gl blend functions, and any arbitrary gl rotation matrix (my switch desktops routeinis going to look somewhat like you're entering hyperspace in the Falcon, cheesey and unnecessary, yes, but definately has a high WOW factor.
The communciation is over pipes and it is very fast, no problems there.
The selection mechanism works great, I just render the window ids to the backbuffer and use glReadPixels to get the id and send window events to the clients. The events I send are just like xlib (no Expose events, though!!
Currently I'm just about to impliment the font selection/drawing scheme (arbitrarily scaled/rotated fonts, resolution independence so you can have nice sized, crispy fonts, and possibly use hw routines to aid in anti-aliasing).
So that's where the project stands. The programming model is similar to X w/o a lot of the cruft. Did I mention it's really fast? Hopefully I'll have a demo out on sourceforge soon, this is NOT vapor...
Cheers, Mike
Intel transfer the difficult from Hadware to software, for get more power, programmer need more technology. -- chinaitn
One of them being the retarded use of XML on an _internal_ data pipeline.
Thanks for pointing out this obvious design flaw.
If they need to specify a syntax for internal purposes, why did they not choose ASN.1 (ISO/IEC 8824-1) instead?
but it's plenty fast for me. And I don't even have that great of a machine. I should point out i've been running KDE CVS for a while, so don't bother griping about KDE 3.1/3.0/2.x/1.x. ;-D
Stating on Slashdot that I like cheese since 1997.
LOL...troll? how was that troll?
whatever. They give anyone mod points - even 6-digit folk.
In their naming and logo conventions..
Unless they got permission from the record label...
Why ask for trouble like this..
---- Booth was a patriot ----
Looking at the more or less crappy DRI drivers available currently, I doubt that OpenGL (based on DRI, ie open source) will ever suit as a stable ground for a secure and stable windowing system. Not even mentioning that vendors don't release docs (especially on the 3D part of the hardware) these days.
-- The Online Photo Editor - http://www.phixr.com
In a couple of years computers are going to be fast enough that even bloated XML will be good enough. Not only that but I just tried out the 2.6 test kernel and X is a lot more responsive. It's noticably better on slower machines.
What if Digg added local news and a Slashdot inspired comment karma system? ---
http://houndwire.com
So, not only are they using one of the least efficient on-the-wire protocols known to man, they're using a ghettoised WAP-orientated XML binary format.
And they are going to handle vectors with SVG.
This is what you would get if you asked a marketer to write a press release for an X replacement. There's no technical merit shown here at all.
how'd you get full window resizing in windowmaker? I thought it wasn't supported (just dragging)
By replacing Unix domain sockets with hyperqueues (about twice as fast), and the X protocol with XML (an expansion of what, 5 times, 10 times?) you expect things to get faster? Somebody needs to check their math.
How about just adding a hyperqueue option to X?
(And yeah, I know, the X Server isn't the bottleneck anyway. Heck, you can implement an X server in Java and still get reasonable performance (well, to a point), so it's clearly not the bottleneck.)
-- Alastair
Does it require the newer Augeri kernel or will it run on the old Perry kernel? Okay, that was bad...ahemm...
This quote by Bill Joy sums up XFree86 for me; That reflects a lack of design discipline, which means that as the system grows, so does the ambiguity of the software itself. The result is a system encrusted with multiple layers of things that weren't really designed in so much as bolted on
The point is that users who desire to use a rich desktop environment (KDE or Gnome) suffer because of the extra layer of abstraction provided by the toolkit and needed to provide that richness.
X may very well be quick, but to be truly usable, in the sense that we understand usability when speaking of modern GUIs, a toolkit and other functionality is needed. As soon as that is added, performance decreases.
I think a redesign is needed and this project at lease takes steps to address that.
This space for rent.
Could this get rid of the speed problems of XFree86 while still retaining Xlib compatibility?
There is no "speed problem". XFree86 is a client/server window system, just like Windows and MacOS. All of them require IPC for clients to communicate with the server. Unlike Windows or MacOS, X11 has been designed for this mode of operation from the ground up, which is why most of its calls are asynchronous and why most toolkits can deal with that. In contrast, Windows and MacOS support applications and programmers that assume they are running no top of a framebuffer library. And the X11 protocol, Unix-domain sockets, and its shared memory mechanisms are about as efficient as you are going to get.
These days, X11 desktops like Gnome and KDE are slow on low-end machines not because of anything having to do with X11 but because they are big, complex pieces of software that haven't been optimized or tuned very well.
"handhelds are also light on memory, so a more "cut-down" version of X..."
I think X's memory consumption will pale to the use of XML.
X11 is happy to use whatever transport protocol you like. It used to run over DECnet, and if HyperQueues are twice as fast as Linux UNIX-domain sockets, it may make sense to add HyperQueues support as an alternative transport mechanism for X11 in Linux.
Adding this sort of thing to X11 is trivial because it has been designed from the ground up as a client/server system (unlike Windows or Macintosh, which have become client/server only comparatively recently).
I guarantee you that running the standard X11 protocol over HyperQueues is going to be faster than running any kind of XML-based protocol over HyperQueues. (Note also that work is underway to add display-side stored SVG graphics to X11 to give you DisplayPDF-like capabilities.)
Overall, with X11, you can get the best of all worlds: stay backwards compatible and actually be more efficient than Frontiers. There is no need to throw out X11 just to use a new transport mechanism.
Who talked about WM's? Apparently you did, but I was talking about the entire desktop, not just the WM.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
It seems to me that once again we are utilizing the power of open source against ourselves. The plain truth is that X11 is HUGE!!! It's based on code that was developed to function on VERY primitive hardware. Instead of changing that code, It was simply added on to. This does make X11 run quite slow in some configurations, regardless of the windomwanager and whatnot.
My suggestions - take what we have learned from X11 -> start a new windowing system from nothing and develop a system DESIGNED for todays insane hardware. I would volunteer but my coding is less than up to par to develop a fast windowing system.
A nice option would be ports of the XFREE86 libraries which could utilize the new windowing system for those folks that want to continue utilizing lightweight X applications.
Just my $0.02
Possibly, who knows?
Well, I guess that answers the above question...No. Even if it may be technically possible to use XML and fix the speed problems, I wouldn't trust that someone who chose XML for this sort of protocol would actually be able to pull it off, until I saw the completed code.
"Those who would sacrifice essential liberty for temporary safety deserve neither liberty nor safety."
I am not an expert in X. Most of the X code I have written is for the very specific application of visualizing numerical data.
I find X really difficult to use as a programming
interface and I suspect many others do as well. There are ~10,000 pages of documentation of X and not an example in the bunch. I think this is why so many layers (Motif and on up) are built on top of X. If it is the upper layers that are slow, it is still the fault of the crappy API that the layers are necessary. It just shouldn't be as hard as it is to put up a window with a few buttons.
The truth is an offense, but not a sin.------R. N. Marley
Many functions run unaccelerated on cards that have all kinds of cool acceleration features... Are you aware that gtk pushes everything as a bitmap through the X protocol for each expose event?
Thank You. No one knows that; or seems to care. I'm currently playing around with a P200 with an S3 Trio64 that gives better (single pixel) Xperf results with the VESA driver than with the (accelerated?) S3 driver. KDE seems to run faster with the unaccelerated driver, which is completely unexpected.
XFree has little to no information on problems like this because they discourage discussion of performance to avoid playing favorites among video card manufacturers. There needs to be someplace that Joe User can go to get realistic advice on graphics performance in Linux, something besides the usual "buy an ATI/nVidia" spiel.
I think it's a good thing that these type of articles get posted once a week because someone needs to start talking about this; it is a serious problem that most noobs think graphics performance on Linux sucks and everyone just tells them that it doesn't or that they should use something other than KDE/Gnome. It seems that graphics and, by extension, gaming are the only areas left to hinder Linux from widespread desktop adoption by the average Windows user.
"I assumed blithely that there were no elves out there in the darkness"
actually I had an app that drew it's own resize handle INSIDE the WindowMaker resizer and I used that.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
GNOME > Bonobo > Orbit > LibrSVG > GTKX11 > GTK back end > Glib > X11 > CPU > GPU > Display
you include Bonobo & Orbit, which are not part ogf GTK+ last time I checked and only come into play for inter-process communications (in such situations, I believe KDE also uses Kparts or whatever has substituted it).
BTW, you are only counting software layer by name, while you should consider how 'deep'(read: average number of internal sub-layer) each layer is: two tin layers can be faster of a thick one.
I am not saying that GNOME is faster than KDE: only that your example show nothing.
Ciao
----
FB
A lot of people are talking about speed and responsiveness issues with regards to XFree86, Win32 and the various X replacment projects. So I'll interject with a real-world example.
At my work we design and build medical imaging systems that aquire their imaging data in realtime. Our current shipping system has been around for five years. It uses a i486 processor, 16MB to 256MB RAM (depending on configuration), a realtime UNIX OS, and a really old Xfree86. It's currently the number one premium system of its type.
But new management has come in, and they're Windows people. So the new system to replace it is to be Windows based. The new system has a P4 1GHz, 1Gig RAM, Windows XP Embedded, and of course, Win32.
The imaging data is aquired and displayed in a separate GUI layer at the rate of about about 16 FPS. Surprise! Win32 isn't fast enough for this. No, Win32 isn't drawing to that special layer, that's done in hardware, it's only drawing the labels and data fields on top. But it's too slow! In order to get any usefull performance out of the new system, they had to abandon Win32 for drawing and use DirectX.
But the old system could handle it just fine. In other words, a XFree86/Motif system running on a 100MHz 486 could redraw GUI text faster than a XP/Win32 system running on a 1GHz P4. That's right. Win32 is significantly slower than XFree86 when it comes to your normal everyday widgets.
Don't blame me, I didn't vote for either of them!
The majority of comments have correctly pointed out that the problem with X is not the core. What Linux needs now more than ever is for hardware manufactures to help with sub-system optimisations. I still think the idea of a Linux friendly award might be a partial solution. Tux is becoming very well known, (especially in the asian market place), so a happy penguin sticker might work. The guys at RedHat and Suse could sponsor something like this. I have an cheap 1999 P11-P111 mainboard p6setML, it came with all the needed Linux drivers on a CDROM, amazing. Companies that do this need to be recognized for their efforts!
OH THE SHAME I fell off the wagon and use sigs again!
I propose that we code XFree86 from scratch by putting an infinite number of monkeys at an infinite number of keyboards for an infinite amount of time.
So, just in case there was any doubt that this entire project was entirely vaporware...
Had you actually bothered to read the article, perhaps you would've noticed that they do talk about switching to ASN.1, and that they plan to start with the XML Schema language for debugging purposes so they can verify the correctness of protocol constructs being created by both their client libraries and the server. They even show how XML maps directly to ASN.1.
What about the Y server that was brought up last week? That intends to follow X by keeping the things X does well and fixing those where it lacks.
I have no sig, the eyebrows seal the deal. That's right. Eyebrows.
you used "XML" and "could this get rid of speed problems" in the same sentence.
not only are the two DIAMETRICALLY OPPOSED you show no evidence of X having serious speed problems.
As we all know, this is wrong. I have a PIII 800 with a GeForce4MX and with nVidia's drivers installed KDE widgets (kdelibs on top of Qt) and windows display 30% faster. Having troubles with speed? Make sure you have the correct drivers installed.
"It's here, but no one wants it." - The Sugar Speaker
XML is not a protocol, but this is.
BEN: Yes, indeed. If it's a fast ship.
HAN: She's fast enough for you, old man.
From http://journeyos.sourceforge.net/
Furthermore, we have been notified of some inherent design flaws in one of the core mechanisms of JourneyOS, which was to be used as part of our upcoming GUI system. We have received proof-of-concept code showing that use of the IA32 memory segmentation mechanism for IPC is an inherently dangerous practice, and consequently is not suitable for a general purpose operating system.
I'd like to see copy and paste, if offered at all beyond basic text and bitmap, offer a range of MIME types and have the pastee choose which one they want. If the cuttee is closed with stuff on the clipboard, it might have the choice of writing out all of the offered MIME types, reducing the offering to a few of the most common types and writing those out, leaving a stub active to handle any paste, exiting but being reinvoked (cuttee specifies how as part of the cut op) to handle any paste.
If it had to be reduced to basic types I would like four: raw text, rich text, bitmap and vector-graphic. Probably the easiest way to do rich text right now would be an HTML subset, but a well-defined XML schema seems to be the path forward.
Right now copy and paste is treated as completely different to import/export, and I believe this is a mistake. App writers have to create two completely separate sets of code, and rarely do both well. Compare what OOo and KOffice know how to import and export with what happens when you copy/paste around them.
It should be possible to treat copy/paste as a special case of import/export, and an offer/accept MIME cycle would allow a "meeting of minds" between the apps to decide what format is best. "Paste special..." would be fabulous because you could select not just "Plain Text" etc but from a list of mutually acceptible MIME types, meaning that you could paste a graph as a graph if both apps understood it, or as a scalable vector, or as a bitmap, or as rich (possibly including the values graphed) text or plain text. Most importantly, the app (or library) author would only need one (albeit marginally more complex) set of code to do it, improving the odds of doing both well.
Got time? Spend some of it coding or testing
Fun! SVG -> Display via nothing but XSL:T! ;-)
Karma: It's all a bunch of tree-huggin' hippy crap!