Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

DirectFB: A New Linux Graphics Standard? 437

Posted by michael from the X-reigns-supreme dept.
Spy Hunter writes: "Some people really dislike the X Window System. DirectFB seems to be the answer to their prayers. Building on the framebuffer support available in recent Linux kernels, DirectFB adds hardware acceleration, input devices, and window management. It has been made (and LGPL'd) by Digital Convergence as a Linux video/television solution, but it is much more than that. It has the potential to replace X for Linux desktops. You want a transparent terminal? How about a transparent video player? Development is proceeding rapidly, with a GTK port and even an X server for legacy apps in progress. Could this be the future of the Linux desktop?"
This discussion has been archived. No new comments can be posted.

DirectFB: A New Linux Graphics Standard? More

DirectFB: A New Linux Graphics Standard?

Comments Filter:

  • AHHH (Score:2, Interesting)

    by Xzzy ( 111297 )
    Who else felt their heart race when they saw that 'digital convergence' piece? phew it's just some dudes in Europe borrowing the name.

    I wonder if the Texas guys with the colon in their name are gonna try to sue..

  • Supported in ClanLib IIRC (Score:2, Interesting)

    by Anonymous Coward
    The ClanLib Game SDK even supports DirectFB directly, so some cool games will be available under full speed.

  • They're nothing like each other! (Score:5, Informative)

    by CaptainAlbert ( 162776 ) on Tuesday October 23, 2001 @07:57AM (#2465230) Homepage
    (a) DirectFB is a thin abstraction layer over graphics hardware; ideal for blindingly fast games, video rendering, etc. Sure, that could be useful.

    (b) The X window system is a network-transparent graphical desktop environment based around the client-server paradigm. Sure, that could be useful.

    You can't really have it both ways. It would probably be true to say, though, that the need for (b) is dying out, and the need for (a) is growing. But that's not what the headline was saying.

    • Re:They're nothing like each other! (Score:5, Insightful)

      by Obsequious ( 28966 ) on Tuesday October 23, 2001 @08:17AM (#2465311) Homepage
      I think that's a bit too simplistic a notion.

      All X is really about is adding network transparency to GUI apps. To accomplish this, the protocol has a notion of windows, window managers, decorations, etc. There's nothing about X, however, that really has anything to do with hardware. X has no provisions for hardware acceleration or transparent windows, for example.

      You're confusing X the protocol with 90% of all implementations of X, which themselves include a framebuffer, hardware acceleration, etc. For example, XFree86 is really just a GUI system that happens to implement the X protocol.

      The main reason that implementations tend to be both a hardware driver and an X server is that the protocol can be a bit hairy to try and "map" into an alien GUI system. (And more than that, Unix systems typically don't even have anything else to map to, anyway, so if the X server isn't providing the hardware driver, there's nothing there.)

      Anyway, the core issue is that there isn't (theoretically) anything that says that an X server has to be a hardware driver. Just look at Hummingbird's Exceed program, which implements an X server on Windows. Writing an X server that would run on a "native" framebuffer isn't such an exotic idea; Exceed actually works extremely well.

      Granted, you can almost always tell that a particular program is an X program, because in practice X does dictate a certain look and feel (since a legacy X app would be running with a widget set that might or might not look like the native set.) But that's why they're porting GTK, and why the X server is for legacy apps.

    • Re:They're nothing like each other! (Score:4, Insightful)

      by rknop ( 240417 ) on Tuesday October 23, 2001 @08:18AM (#2465316) Homepage

      (b) The X window system is a network-transparent graphical desktop environment based around the client-server paradigm. Sure, that could be useful.

      You can't really have it both ways. It would probably be true to say, though, that the need for (b) is dying out,

      My need for (b) is most definitely not dying out! I would find it sad if support for X under Linux started to seriously wane as people put all of their emphasis in having everything work blindingly fast when rendering directly to the hardware on which the application is running. I do play games occasionally, but most of the time I'm using my Linux boxen to do work. Remote shell sessions are the most common, but it's not infrequent for me to use a number of other remote X sessions, which are made possible, easy, and transparent by the client/server architecture of X. I do not forsee any time in the near future where I could hope to run the things I need to run entirely on whichever machine I happen to be working locally on.

      Hopefully, there are enough other people out there like me to keep XFree86 going, so that even if "most people" start using something like DirectFB, X will still be an option. (Much as Gnome will still be an option if everybody starts using KDE, or vice versa; this is the beauty of free software.)

      -Rob

      • Yep.. As computers become ever more connected, remote access becomes even more important. I don't think a graphics environment could survive too long on Linux without at least some form of network transparency.

        Certainly, the X model can be improved upon. The main problem with using X over the Net is that it is very sensitive to latency. It doesn't matter if you have a Gigabit connection -- if you have significant lag (like the ~250ms in satellite connections), X will run like a dog.

        Fortunately, someone came up with mlview-dxpc.. I just hope it can be integrated into XFree86, ssh, or both.

        • Certainly, the X model can be improved upon. The main problem with using X over the Net is that it is very sensitive to latency. It doesn't matter if you have a Gigabit connection -- if you have significant lag (like the ~250ms in satellite connections), X will run like a dog.

          Tell me about it. Especially for those of us who use terminal sessions-- latency is a killer when there's a 1/4-1/2 second delay between typing and seeing what you type.

          I would love to see an "X Replacement," but if it driven by what games need, it probably won't really do what we need X to do very well...

          -Rob

    • I don't know. X works fine on every machine I tried. The only thing about X is it's chattyness on a network. The dang thing is so chatty that you need a good/great network connection to run anything remotely. The need for DirectFB is becoming greater? The only thing I see the speeds that a DirectFB woulde be very useful for is a desktop that is playing games, or watching videos.

      Now, for my spiel on Transparant terminals....I never liked em. I like to run color Xterms and transparant terminals don't do much for me there. No matter what kind of background you use, the colors of the background always kind of blend with the text making it much harder to read. I would not mind things like transparant, attatched dialog boxes ala OSX, but so far as transparant Xterms, I have no use for them. I also don't think a transparant video player would be very useful either. Yeah, it looks cool, but usually when I am playing video, I want to WATCH it not work through or on top of it.

      Personally, I think everyone's major beef about X has been is is being resolved. That would be crappy looking fonts. Anti-aliasing is fixing this gradually. You can now have an anti aliased KDE or Gnome desktop. That's nice. The only other complaint I can see is not so much as a complaint about Xwindows as it is about video card manufacturers. No matter what they do, they have to make money. If that means they withhold source or their spec so we can make good drivers, then, well, it doesn't matter whether you use X or DirectFB. You still have the same problem. X is a good thing. Network transparant applications is a good thing when it's security is implemented well (and we KNOW X has problems there). Let's fix X windows. I know, it's code is arcane and boring, but I can't help but feel that DirectFB feels more like the way Windows does things then Linux and we all know how well THAT works!

      • LBX = Low Bandwidth X (possibly off topic) (Score:4, Informative)

        by Walles ( 99143 ) <johan.wallesNO@SPAMgmail.com> on Tuesday October 23, 2001 @08:31AM (#2465378)
        The only thing about X is it's chattyness on a network.

        There's a standard X extension (?) called LBX that comes with XFree86 and others. Check out the LBX Mini-HOWTO [paulandlesley.org] if you are interested.

        Cheers //Johan

      • The only thing about X is it's chattyness on a network.

        It isn't X that's chatty - it's the apps that use it. Some years ago I developed a couple of simple applications to display some statistics graphically in (pseudo) real-time. Over a SLIP connection on a 14400 modem, one of them worked but the other one didn't. The one that didn't had a little bug that I'd never noticed on a local machine or even over ethernet. The bug was that it redrew the graph elements even when it didn't need to.

        So don't go blaming X for things over which it has no control. OK, so maybe its network model isn't suitable for video players or arcade games - but don't write it off because of that.

      • Low Bandwidth X (Score:2, Informative)

        by Doke ( 23992 )
        Have you tried Low Bandwidth X (LBX) [linuxdoc.org]?

        I think systems like directFB are a step backwards. XFree86 already has shared memory and direct draw extentions (see vmware), designed for high speed local graphics. When running remotely, the X library falls back to it's normal protocol, and the apps slow way down, but still operate. The network transparency of X is far, far too usful to encourage a crop of apps that can't use it.

    • It would probably be true to say, though, that the need for (b) is dying out, and the need for (a) is growing.

      The network transparency of X is immensely useful (and brilliant). I'd rather take the superior, albeit slower, architecture of X over any super-fast, yet functionally neutered, architecture.

      Sometimes I wish all of those "web standards" were thrown out in favor of a newer better version of X. Imagine: web applications could be the real thing, and all that (MS)HTML/(MS)XHTML/(MS)XML/(MS)JavaScript cacaphony could be tossed.
    • But making claims that that you can't have it both ways is being ignorant of the fact that X is merely a protocol and XFree86 is an implementation of a graphics renderer and input system that fully supports that protocol- you can have an X server sit on top of the thin framebuffer layer (In fact, they HAVE one already.) that drives the framebuffer layer and receieves inputs accordingly.

      It's not just "a" or "b" it can be "a" and "b"- and for many things, that IS what you want.

      When you're talking about things like tuner cards, strictly speaking, you're never realistically going to be able to do a video push to a remote window- you're going to go to DGA (Uh, that's a hack in XFree86 that allows you to do the DirectFB thing in the context of X...) or you're going to encode it realtime to some compressed format and push the lowered bandwidth data stream to a player on the other machine to be decoded. Otherwise, you're going to need gigabit speeds to do this well for more than one machine. The same goes for videogames, etc.

      • Nope (Score:2)

        by p3d0 ( 42270 )
        Consider the applications. If they are written in terms of DirectFB, you don't get network transparency. If they are written in terms of X, you don't get performance.

        (Unless they are claiming that X-on-DirectFB will be faster than XFree86.)
        • That's where you can use something like GGI [ggi-project.org] as an abstract library over either backend. Other infrastructure, like GTK or QT, could also be ported to both backends.
  • If you use hardware acceleration for your GUI, like people want for OS X, how will apps like VNC display this, if it goes straight to the graphics card?

  • There are many apps that will need to be ported over in order for this thing to fly. I do see that they do have a gtk port so that will help in getting some application ported over. I would like to see the best of both worlds here. They can even port Xfree86 to DirectFB but that will only defeat the purpose. What I will really like to see next is the Troll Tech libray port of directfb which will really another good portion of apps to directfb. if we can do that the mayabe in a few years we can see this as the next new standard.

  • Goodbye Platform Interoperability... (Score:3, Insightful)

    by LeftHanded ( 160472 ) on Tuesday October 23, 2001 @08:07AM (#2465267) Homepage Journal
    which is the whole point of X. You can have an X server running on Windows (ptui), Linux, *BSD, Solaris, Tru64, AIX, HP-UX, Max OS X, etc, etc, etc and display clients that are actually running on one of the other bazillion X supported platforms. The DirectFB solution works only for the Linux framebuffer. If you hate X, great, then this might be a place for you to develop tools and applications. For the rest of us old hand UNIX folks who have worked with X for years and years who love the network aspects of it, we'll stick with what we got. Even if developing software for it is way hard without several layers of software abstraction (toolkits).
    • And you can have an X server running on DirectFB!
      The current XDirectFB uses DirectFB in fullscreen mode, it does its own window management. Just think of a rootless X on DirectFB, like on MacOS X. You could have X applications going through the server and DirectFB applications or games running directly at full speed. When the X server has been enhanced to use DirectFB's window management it would be easily possible to set the window opacity (ranging from 0-255) of any legacy application.

      X is a great technology and I think DirectFB is rather a good base than a replacement of this technology.
      • And you can have an X server running on DirectFB!


        Which completely misses the point. Yes, it means that you can display remote applications on your directfb machine. But you can't do the reverse -- display your directfb application on a remote machine. At least, not without kludging multiple display targets into gtk, something akin to what the libggi folks did long ago.

        • Re:Goodbye Platform Interoperability... (Score:4, Insightful)

          by ceswiedler ( 165311 ) <chris@swiedler.org> on Tuesday October 23, 2001 @09:18AM (#2465605)
          If I were writing an application which had a hope of running remotely (a standard windowed word processor for example) I would write it to X. But if I were writing a new flight simulator, I would know up front that there is no hope of running it remotely, because it needs direct hardware acceleration, and I would write it for the DirectFB layer.

          This is more like DirectX than anything; a way to bypass the high-level windowing system to write directly to hardware. As people have said, it doesn't replace X completely. But I would rather have a X server layer on top of a direct-hardware layer, than a direct hardware piece hacked into an old X server.
      • You could have X applications going through the server and DirectFB applications or games running directly at full speed.

        So why don't we put the hooks in X so that full speed/direct to hardware access is possible? O whait? That's DRI...! XFree86 has bugs, sure, but it isn't the monster people think it is. Most of the memory the server uses are apps storing images and stuff server side.

    • Many modern apps, the ones I care about anyway, are coded to either Qt or GTK. Why would I be saying goodbye to platform interoperability? This makes no sense?

      On Linux I would benefit from an efficient Qt or GTK implementation on DirectFB without running any X. I wouldn't ever have to see any ugly primitive X applications either.

      On non-Linux platforms, Qt and/or GTK can be implemented in the traditional X fashion, or in any other fashion if that platform also has something more efficient.

      Modern apps will still compile and run.

      And if you like X apps (i.e. non-GTK and non-Qt), there is nothing here saying that you can no longer use X. X isn't going to disappear. Individual apps that use GTK or Qt can still use a Qt or GTK lib that supports X to draw on a remote display.

      On Linux, on the X server end of things, you could use only one single X server. Yea! No more xf86config and all that crap. You could still see traditional ugly X applications or you could see remote GTK or Qt applications. Local GTK/Qt apps could be more efficient, going to DirectFB. The local X server could be iimplemented in a manner much like on some other platforms, where the X windows are integrated into a local window system -- or could use a traditional X root window.

      Anyway, just my opinion. But since it makes things simpler and cleaner, I'm sure many old school people will be against it. Just my opinion, but I think this is a step forward. I'm sure it will encounter lots of resistance.
    • honestly, over a 10mbit LAN X isn't fast enough to run the applications I use everyday. GAIM, WordPerfect, and Netscape all run too slow over 10mbit to be worth even bothering.

      I switched to 100mbit recently and it is better but not exactly what I would call some sort of godsend that would make me say that X is worth using just for network application.

      X is a standard across many platforms and I believe that is to singling Linux out a little more on its own but I do think it is a good option for those that want to use it.

      Hope it all works out for ya :)
      • That's odd. I have a 100Mbps home network and I've even played older arcade games in xmame across it with no noticeable slowdown. Once I played Space Quest V across the network using DOSEMU, and that was a little slow at times, but not bad.

        The only time I had speed problems with X was when I visited a friend in New York and ran my KDE desktop from my computer at home (in Phoenix, AZ). Probably because my DSL upstream rate was only 128kbps.

        I've used email and news applications across my 100Mbps network and couldn't even tell they were remote.

  • A way to reduce software costs .... (Score:4, Interesting)

    by LL ( 20038 ) on Tuesday October 23, 2001 @08:10AM (#2465277)
    ... is to refactor VNC to multicast directly to a bunch of Linux frame-buffers (a la SunRay). If companies are insisting on per CPU licensing and refusing to offer floating licenses (think legacy apps) then by running it on a half-decent back-end server (with fast storage) you can amortise the cost of the software over a wider geographical region, as well as support multiple legacy versions. Of course, you better have a decent network first.

    BTE, whatever has happened to embedding X into the web browser (X11R7? Broadway?) How come that's not being used to port some of the older X utilities across to work over the internet?

    LL
    • I, for one, would just LOVE to see the ability to actually use a SunRay with a linux server. I don't suppose sun is going to fork over the specs though...

      Just think of it. Those awesome SunRay terminals, without the need for a rediculously expensive Sun server.

  • Kudos to the LinuxTV.org guys (Score:3, Informative)

    by Anonymous Coward on Tuesday October 23, 2001 @08:11AM (#2465282)
    These are the guys who run the Linux DVB (Digital Video Broadcasting) aka Digital TV projects, if you get a DVB-s (satellite) board from Hauppauge their package does amazing things, you can save the MPEG2 transport stream directly to disk and have a TiVo like system without any A/D conversions in the process. They have even garnered support from Nokia for their DVB API, Nokia want to use Linux in their STB's, the Media Terminal [slashdot.org] has been well publicised on /.

    I believe the DirectFB package was originally designed to do onscreen graphics for a TV link up so you could have alpha channels overlaying the MPEG stream.

    Very clever guys... my hat goes off to them!

  • I wonder... (Score:4, Funny)

    by Pseudonym ( 62607 ) on Tuesday October 23, 2001 @08:12AM (#2465284)

    Does it come with an open sourced barcode reader driver?


  • I think that this has some potential. It said that it has X compatability, so there is not legecy issues. and porting the KDE/GTK+ applications is as easy as porting the tool kit
  • I found that the abstraction functionality has gotten so minimal in the newer display libraries that it's easier just to access /dev/fb0 directly.
    If you're doing all your graphics in OpenGL there's no reason to abstract /dev/fb0. FBDRI does all the /dev/fb0 calls.

    Since no-one's writing desktop software anymore the framebuffer device is ideal for the new one-device one-purpose market.
  • Why is so much of the innovation in the Open Source field taking place outside the USA?

    Why is it that it is European governments [kbst.bund.de] that are considering moving to Open Source, [newsforge.com] and not USA governments?

    Why is it that it is big companies in the UK that are grouping together [tif.co.uk] to fight Microsoft's restrictive licensing, and not the USA?

    Is the USA in danger of losing its lead in the technology sector?

    • Is the USA in danger of losing its lead in the technology sector?

      Yes. A combination of a monopoly in part of that sector, which incidentally uses its huge financial power to great effect on the government, and the stranglehold of the huge powerful USA entertainment industry on our (eminently purchasable) government, threatens to choke of technical innovation altogether (while meanwhile outlawing open source and free software). It hasn't happened yet, and it doesn't have to happen, but if you deny that there are serious threats that it's happening, you're either a not-paying-attention optimist, or an apologist.

      -Rob


    • Why has this been modded as flamebait? It is a serious question.

      Just because you don't agree with it or don't like what it says, doesn't mean it is flamebait.
    • One of each of the complete set!

      Moderation Totals: Offtopic=1, Flamebait=1, Troll=1, Insightful=1, Underrated=1, Total=5.

      Do I win a prize?

  • To the Naysayers (Score:3, Insightful)

    by Outlyer ( 1767 ) on Tuesday October 23, 2001 @08:21AM (#2465327) Homepage
    A couple of small points:

    While main of you correctly point out the lack of network support in this, let's be honest here, the majority of users want a fast, pretty desktop. This would be the way to do it.

    Applications are not a problem; both GTK and QT have abstracted the window drawing from the widget set (GDK for GTK) so someone could potentially relink (not necessarily rebuild, if the symbol tables stay the same) their apps and have a wealth of stuff to choose from.

    I like the network transparancy in X, but what is to keep you from running X for remote applications, and using DirectFB for your desktop? X is nice, but it's filled with lowest-common denominator decisions, and the majority of people polled (cough) want to run with things like alpha blending, anti-aliasing, and windowed 3D. X supports them, but not without a lot of pain.

    So, if you want to use X, you could potentially keep it; if you want DirectFB, you can use all your GTK/QT apps (theoretically) Why rain on someones parade when both crowds could potentially win here?

    • good point, an remote Xsession could be displayed in a window drawn by Directfb....all you need is to have the server installed on the machine, you don't actualy need to have your apps render from it.

    • Re:To the Naysayers (Score:4, Insightful)

      by Znork ( 31774 ) on Tuesday October 23, 2001 @09:40AM (#2465749)
      The fast pretty desktop is best achieved elsewhere. The problem isnt X, the problem is insufficient use of hardware acceleration in X device drivers and/or software bloat.

      Yes, X supports these things. And, heck, OpenGL/GLX is even a network transparent protocol that too, so you can even run your hardware accelerated remote-displayed 3d programs over the net. And networks get faster all the time. So, please, concentrate on making these things less painful in X.

      Any attempt to replace X will only end up going back in time half a decade, reimlementing X and eventually being back where we started.

      DirectFB sounds great. For what it's used for. But X will never be replaced as the basic GUI layer for Linux/UNIX operating systems. No such attempt has ever caught on (and there have been a number of them), and none ever will simply because the only reason to is when you have absolutely no use for network transparency and you have far too little resources to support X. Today that means calculators and lowpower PDA's, and the occasional non-networkable consumer product, and with the way things are going, within a decade or two those cases will probably involve the device in question being a museum exhibit.
      • ...X will never be replaced as the basic GUI layer for Linux/UNIX operating systems. No such attempt has ever caught on (and there have been a number of them), and none ever will...

        That's a pretty narrow and short sighted statement if you ask me. As if X were the only networking protocol out there. Not to mention, there is already an X server running on top of this thing.

        My only worry about DirectFB is that it runs on Linux only. I've played with it on Linux before and I thought it was pretty cool, although quite immature yet, but I normally run FreeBSD. If this can't be ported to FreeBSD and other non-Linux platforms such as Solaris, then it may not stand much chance of being widely used.

  • Wow, this is great great news. Currently I run X 4. whatever. But when I installed mandrake it gave me a choice of X4, X3, and X3 with experimental 3d hardware accelleration. I really need the stability and features of X4 with non-experimental 3d with my TNT2. if this is any good, I'm so there. As long as I can still use ssh to X-Forward stuff from the CS lab.
  • I believe that a lot of folks (including me) maintain Windows machines for games. However, not just because there are more titles - I find the games run far better on my windows box (which is a lesser machine) than on Linux. I'm not sure why exactly, though I imagine tight integration with video hardware/acceleration counts for a lot and I've also found that sound doesn't mesh with visual elements well. It seems this type of thing might help in the raw performance category for gaming and help make Linux a top-tier gaming platform, rather than a not-so-great second-tier solution.

    Now, I use my Linux box as my development platform, web server, mail server, etc, but I've got to keep Windows around for gaming.

  • i'll stay with X. (Score:5, Insightful)

    by Rev. DeFiLEZ ( 203323 ) on Tuesday October 23, 2001 @08:38AM (#2465406) Homepage
    I am kinda upset to hear how ppl are so willing to ditch X for faster video/games. i get more then enough frames in quake3/desent3/heavygear 2 (the only loki games i own) and i dont drop frame in video (even divX) and as i only have 400Mhz to play with i dont understand why ppl are think X is so slow.

    however being able to ssh into any box and typing export DISPLAY=my_local_box:0.0 and then being able to run all the the remote Xapps on my box is is one of the greatest features on the planet.

    if you want to increase the speed of your X its not replacing X, its replacing your KDE and gnome with fvwm2 (which is what i use) or even blackbox.
    i see all these comments about enlightenment and KDE and gnome ( although i use GTK, not gnomelibs, _GTK_ for my devel and most usable apps) i shudder, because they are so slow, and then the same ppl complain about X, thats just wrong. if you want a fast system, a recommend the following:
    • replace KDE/enlightenment/gnome with fvwm/blackbox/twm
    • replace staroffice with abiword/gnumeric
    • replace kmail with mutt (read the help mutt as more features)
    • change your 14meg wallpaper with xsetroot -solid black


    granted transparent video will have some important uses in editing, however what has to ask how is it done in irix platforms now, is there a hardware solution that we can not compete against because its just so great?

    i want X, maybe they can merged, kinda like now ppl have -nolisten tcp .. if they turn off networking they get directfb support.

    -rev
    • They HAVE an X server- it's just not required for everything like it is with XFree86.
    • Even using DGA2 and all the other latest X speedups, the same program running on Linux is in my testing between 10 and 20 FPS slower than Windows *on the same hardware*. That's IMO unacceptable *especially* for e.g. 400 MHz systems like yours.

      FYI, framerates in OpenGL games aren't the issue since with DRI/DRM/the NVIDIA driver they pretty much just bypass X anyway. I'm talking about blit speed for windowed or fullscreen 2D games, which DirectFB sounds like a terrific solution for.
    • * replace KDE/enlightenment/gnome with fvwm/blackbox/twm

      You forgot xfce [slashdot.org].

    • Massive security hole buddy (Score:4, Informative)

      by Srin Tuar ( 147269 ) <zeroday26@yahoo.com> on Tuesday October 23, 2001 @09:35AM (#2465710)


      however being able to ssh into any box and typing export DISPLAY=my_local_box:0.0 and then being able to run all the the remote Xapps on my box is is one of the greatest features on the planet.

      Ouch- allthough your command to start the X proggie will be secure, the windowed program itself will be going over an unsecure channel if you use that method. (all your click are belong to them)


      You should really look into X-forwarding (read man ssh).


      Regardless- I too like the network transparency that is offered from X. If the damn X protocol would support SSL or something like it natively, then it would seriously speed up secure remote graphical logins. (search google for tcp over tcp to see why)

    • Why are you forwarding X connections manually when you are using SSH? SSH does this for you. PLEASE read up on X forwarding in SSH. It's excellent. And secure.
      What you are suggesting is not secure at all.

    • 1) Use port forwarding over ssh instead of DISPLAY=insecure_as_hell. Please, firewall X (6001-6006)!

      2) Component programs like Gnumeric are cute, but with Gnome it's kind of all-or-nothing for the novice user. This is an issue since X performance is not up to par with Windows in many respects. Believe me, I've set users up with both Gnome and other WM's (fvwm, Windowmaker, etc.) and they all prefer Gnome. Even though it sucks ;-)

      3) Ok, maybe the Mutt comment bears the Insightful label :-).

      Bottom line is that most X apps run well on a local workstation, and if you're not tunneling X from, say, an SGI Onyx in New York to a demonstration on a workstation in DC, you may not really want the overhead of being able to do so. Don't get me wrong, X is magically delicious for a handful of users, but most admins (myself included) can control things very well with a terminal or VNC, and most users are never going to use the most powerful features of X, rendering it needless bloat for them. DirectFB solutions would make Linux far more attractive for these sorts of users are their managers.

    • i get more then enough frames in quake3/desent3/heavygear 2 (the only loki games i own) and i dont drop frame in video (even divX) and as i only have 400Mhz to play with i dont understand why ppl are think X is so slow.

      It's not necessarily slow, I just think it's backwards to be adding "direct" support to X. It should be the other way around. Look at it this way, how often do people take advantage of X's remote ability? Less than 1% of the time, I assure you. With DirectFB, you wouldn't lose your ability to work remotely, it would just be an extension (the reverse of X basically, where it's _directness_ that is an extension). X is optimized for running over the network. DirectFB would be a desktop that's optimized for running locally, ie 99% of what most people are doing.

      Now, about games. I read a quote on directfb.org someplace about a guy not satisfied with the current DirectFB X layer (for running X programs). Since it doesn't (or didn't at the time) support DRI/DGA, he couldn't play his games on DirectFB. So he said something like this, and I swear I'm not lying when I type this, "I guess I'll use DirectFB for my normal apps, and X for games." Tell me that isn't backwards!

      There is an obvious problem here.

    • Re:i'll stay with X. (Score:4, Insightful)

      by Arandir ( 19206 ) on Tuesday October 23, 2001 @01:00PM (#2466976) Homepage Journal
      I am kinda upset to hear how ppl are so willing to ditch X for faster video/games.

      I agree. X is powerful, flexible and proven. It's like a 4x4 truck. What can you do with a 4x4 truck? Haul heavy loads, go offroad, pick up your date for dinner. But there's a lot of people who want to drive a sports car instead. What can you do with a sports car? Pick up your date for dinner. Period. Personally, if a date doesn't want to ride in a truck, I'll find someone who isn't so shallow.

      If you can make DirectFB *identical* to XFree86 in functionality, then fine, I'll use it. But otherwise keep it away from me. Frankly, making gaming the primary goal of Linux is an incredible step backwards.
  • You want a transparent terminal? How about a transparent video player?

    Yea I do! Its call "Default Install" on Mac OS X 10.1. The best part, I have it today. I won't be waiting for it.

  • X isn't so bad... (Score:5, Informative)

    by Junta ( 36770 ) on Tuesday October 23, 2001 @08:41AM (#2465429)
    I keep seeing people dissing X as a horribly inefficient system that is long overdue for replacement, but the justification always seems to be a myth.
    First off, the complaints are generally levelled against what they see in a particular implementation of the X protocol, not the protocol itself. There seems to be no acknowledgement that while X servers of the past may have had implementation problems, that we have moved on and produced much more efficient and well-featured implemntations, particularly XFree. Through X extensions, XFree has become an X server that keeps the good of X, and improves on the bad aspects of older X servers.

    The main gripe I see is "X is slow!!". Well, with XAA, X gets the same sort of acceleration as Windows display drivers for ordinary stuff. This requires that good drivers exist for your chipset, which is a good bet nowadays, but not as likely as Windows. Not XFree's fault, and it's clear that any FB based solution won't help matters in this regard (driver support)

    People also have complained about 3D performance. XFree4 has DRI which really works well to address the issue. For Video playback, there is XVideo which provides good access to hardware scalars and filters. There is work being done on an XMovie extension that could provide access to hardware video decoders, such as the MPEG-2 decoder on All-in-Wonder cards (though I haven't heard much about it lately). Another complaint I hear is that it is ugly, that it lacks the bells and whistles of 'modern' systems. Well, there is now the XRender extension which can be used to provide translucency (if anyone bothered to implement it) and in turn provide both anti-aliased text and sub-pixel sampled font rendering (ala Window XP's cleartext).
    Those who complain about X and say it needs replacement need to be a bit more educated. If you look at the projects that have aimed to replace XFree in the past, you see a very interesting pattern. Berlin is a good example of this. They set out to provide things that at the time people said "X cannot accomodate these features", but by the time Berlin progresses to any usable state, XFree has most of these features in XFree4. Let's face it, XFree in particular is a good system that can continue for quite a long time, and has only improved with age, contrary to popular belief.

    • Re:X isn't so bad... (Score:3, Insightful)

      by Alomex ( 148003 )
      I keep seeing people dissing X as a horribly inefficient system that is long overdue for replacement, but the justification always seems to be a myth.

      Here's one. The whole X window system was designed from the get go with the idea of having a dumb terminal at the user end. As the design progressed, it became apparent that the X-terminal would require some higher intelligence. In the end X-terminals have a fully functional CPU that is being wasted by 90% of the function calls which were designed before the change of CPU demands.

      • Re:X isn't so bad... (Score:3, Informative)

        by rkent ( 73434 )
        Hmm... but if you're running X on localhost:0, it's basically the same difference. The "dumb terminal" is on the same machine as the "powerful server," so it's a wash. Doesn't seem a whole lot worse than a packaged graphical solution designed to only run on the local machine.

        Then, you still get the benefit of being ABLE to run an X server on a remote machine, and not being bound by its processor (whatever that may be). My personal gripe is the network bandwidth it requires for a good connection; I've never really been able to run an X session over the modem to my university account, which at times would be the whole point.

    • X is nice, but... (Score:3, Informative)

      by Svartalf ( 2997 )
      You're missing the point that you're inserting a raftload of indirection in the picture when you use X as it's currently specified. Everything HAS to go through your TCP/IP stack. While it's GREAT for networkability (and I'd not ditch that feature), it's not as great for apps needing peak performance locally- it requires more muscle on the machine doing it this way than if it were direct.

      DirectFB was developed not for games, but for media convergence devices (Entertainment systems with Linux running as the core OS, etc.)- other people are latching onto it because of the above problems. DirectFB ditches the need for hacks like DGA (which is needed for things like tuner cards) and allows you to run things like video on demand systems, etc.

      Oh, and next time, read up on the actual story, not the /. blurb- they HAVE an X server for this and are advancing it as well because for most things, it's better to use X.

      • Re:X is nice, but... (Score:2, Informative)

        by Anonymous Coward
        Everything HAS to go through your TCP/IP stack

        Rubbish. (a) X tends to locally use unix-domain sockets, which can sometimes be zero-copy on linux, and (b) there's a shared memory system that nearly everything uses anyway.

      • Re:X is nice, but... (Score:2, Informative)

        by J. J. Ramsey ( 658 )
        "You're missing the point that you're inserting a raftload of indirection in the picture when you use X as it's currently specified. Everything HAS to go through your TCP/IP stack."

        Wrong. X does not require TCP/IP at all. If everything is running locally, Unix sockets and shared memory can be used. When running across a network, X can use another networking protocol lkie DECnet (though few would want to, AFAIK). TCP/IP is not necessarily part of the equation.

  • Give up $DISPLAY - Never! (Score:3, Interesting)

    by smartin ( 942 ) on Tuesday October 23, 2001 @08:48AM (#2465459)
    X may be old but it has adapted to the times and continues to adapt. Direct frame buffer access is great for games and may be some graphically intensive applications but i'll take the ability to run an application on one machine and display it on another of possibly an entirely different architechure any day. My little pentium 133 laptop is still a very useful machine simply because all it really has to do is run X, i can even access pigs like star office without any problem.

    VNC is a cool and useful hack but X is a better solution.

  • Hmmmm..... (for al my regular readers ;-) (Score:3, Interesting)

    by TheMMaster ( 527904 ) <hp@tPARISmm.cx minus city> on Tuesday October 23, 2001 @08:52AM (#2465474)
    Although the site is almost /.tted it still looks pretty mean and clean to me. BUT
    I really think this is GREAT for the whole linux on the desktop venture, because as much as I love X (and I do) I know it is a very hard thing to do (loving it that is)
    X is bloated, it is considerably slow, altough I must say that with Xfree86 4 a lot of things changed (for the better) the new "modules" system is brilliant!
    But the biggest problem is that for geeks like me and you ;-) X provides us with all we need to prevent phisical activities as much as possible (in other words check your mail on your main machine while sitting on the couch watching TV, not to mention those tedious walks to the server room ;-))
    Fact is that X is the defacto standard when it comes to remote displays, heck, even novell uses it in netware 4 trough 6

    My idea: Port all the apps whatever to this new platform because what I've seen off off it, it is pretty darn nice for desktops, but we need to develop some kind of deamon which allows displays to be exported over a network when the display is NOT local.
    Now it doesn't matter weither or not the display is on the localhost or not, clients always connect using the X protocol over loopback, this is a waste of resoures, why not only use it when it is absolutely neccecary?
    I'd say make it POSSIBLE for programs to export their display not export them ALWAYS, I have no clue about how to do this, but if some people that know a bit more about X want to help me, we'll set up a project to implement just that, email me if interested, please flame here ;-)

  • X.. (Score:2, Interesting)

    by Forkenhoppen ( 16574 )
    Just a few quick notes about X.
    - it's fairly simple to implement
    - it's a standard
    - it works
    - it's here now

    A few notes in DirectFB's favour
    - a modern, and hopefully clean, implementation
    - good object-oriented principles
    - as a result, fast and easy to program in

    So the solution, as I see it, is a little different. I've looked at Berlin and all those other windowing environments. Look, if what you want is direct access to one video console, then go with DirectFB. But if you want a windowed system, stick with X. Just reimplement it yourself.

    (Although I don't know what to say about Window Managers.. they still seems like a nasty hack to me..)

    XFree86 is old, and is carrying a lot of baggage functionality. What should happen is that it be rewritten to abstract the windowing portions away from the hardware level. I figure that if this is done, it'll be a drastic improvement, stability and OO-wise, over the current arrangement.

    This is the main gripe I've heard, time and again, and it's the one that annoys me, too. So I think someone should do something about it. Start removing this functionality from XFree86, and stuff as much of it as possible into kernel drivers. (These wouldn't have to be included with the standard kernel; it would be enough to have a set of loadable drivers you could download from somewhere else and load into the kernel.)

    I doubt this'll happen, though, because it's too OO. The current linux kernel is monolithic as high hell, and the people behind it support that mind-set. Perhaps there's hope for the GNU/Hurd.
  • IMHO this is a good thing; the more (friendlhy) competition we have, the better the resulting products will (eventually) be. So maybe a year from now, we'll have the choice of which GUI environment you want to start. If you want to do Word processing, email, and other 'normal' stuff, you could do "startx"; if you want maximum FPS for the latest strategy simulation or Quake clone, you could do a "startdfb". Since there's a GTK port, it should be possible to run all your favorite Gtk/Gnome apps either way ...

    Hopefully once of these we'll have an alternative to X. I was hoping for the Berlin project to provide this, but there doesn't seem to be much movement on their front (but then again, I don't follow it closely). Don't get me wrong, I have no major complaints about X (actually like it) but another system geared towards maximum perfromance (at the cost of sacrificing some flexibility) to choose from is good; especially in light of the fact that most modern apps (Gnome, KDE) should be pretty easy to port (./configure & make should suffice) once the base libraries have been ported.
  • Just to be clear: the Digital Convergence [convergence.de] named in the story isn't the same Digital Convergence [crq.com] which gave people a hard time [slashdot.org] for messing with their "CueCat" foo.
  • So will this new system be locking its software's users into X86 and SVGA hardware? One of the appeals of Linux is its ability to run on different platforms. And while I can think of worse things than forcing people to use X86, it seems to me that a new de-facto video standard, probably targeted at hardcore gamers, could break the system.
  • I have been coding in the X windows source for a while now, adding in extensions and etc. All I can say is it is a disaster. The goal of X windows is to retain backward compatibility all the way back from it's initial implementation. What this means is that almost none of the source is ever removed or replaced, it just has wrappers written around it or hacks to decide which source to use. The source is littered with #ifdefs. The code is not very modular either. A change to one section of the source means a change to others to keep things synchonized. Good luck finding the spots to change. For example I added an extension and had to edit the command line argument processor in the main() function, the extension init routine, some hardware initializing routines and ANOTHER commandline argument processing routine. X windows is just so big that when you have many coders working on it at the same time, everything gets out of synch more and more... Oh the best way to find the spots to change is to find where it is segfaulting, and browse a lot of core files.

    Ok, now the only good things about X windows is that.... umm... it's a "standard" which is a word a lot of people like. I think DirectFB will be successful as long as X windows is still around to run all the older Xwindows dependant applications.
    • "The goal of X windows is to retain backward compatibility all the way back from it's initial implementation."

      I'll probably get modded Troll for this but I'm serious about this question:

      How is the above statement (if it is indeed fact) different than Windows and all the flack that it received for years about being overly backward-compatible through DOS?

      Might a forking of XFree86 to drop much of this backward compatibility be warranted here?

    • Most X implementations share the same source. Most of it comes from the main X.org source tree. There are plenty of direct cut and pastes from the X.org tree right into other trees, Xfree86, Suns, etc... The core source of the trees really are not much different. They are suppose to all implement the same standard, so there isn't much room to have a different core system.
  • This is something that Linux can definately use. X is cool, but is really better for client/server desktop applications than as an actual desktop.

    Of course, what would really make this nice is if they can make it easy to set up. The number one newbie problem that I see with Linux is getting X to work. I have been running Linux for a few years now, and configuring X is still a huge pain. Apologies to Frank Herbert, "Who controls the easy setup tool, controls the Linux desktop!"
  • Normally I would be one of the ones saying "Ugh, not another half-ass graphics standard," as I am developer for the GGI Project, which, if very slowly, is creating the ultimate (IOO) cross-platform and cross-display-system graphics API/library. I make no such complaints about DirectFB (well, OK, I do complain about their input system :-) and here is why: DirectFB is coded in such a way that it contains easily reusable, easily understandable graphics driver code. Both DirectFB and X have unique content -- there aren't that many implementations of hardware level blitting/overlay libraries available. Unlike X, DirectFB is modular and developer-friendly. In fact so much so that the current version of LibGGI can use DirectFB's binary graphics driver modules.

  • It is a about damn time!!! (Score:3, Insightful)

    by Arethan ( 223197 ) on Tuesday October 23, 2001 @10:44AM (#2465881) Journal
    Where the hell do I sign up to help!
    Seriously! I've been pushing for the death of X for a long time now. DirectFB is a very promising replacement from the sounds of it.

    As for the network transparency layer, nothing says that you have to lose that. If done correctly, you won't even need to recompile your apps for each different use. Quite simply, assume that every app on a system uses DirectFB instead of X. Now you want to remotely use a gui on that system. DirectFB simply needs to present the ability to run in a detached hardware mode. A client system can attach it's DirectFB to a DirectFB layer on the server.
    The rest would run a lot like X: the application writes it's video output to DirectFB, which saves it in a memory buffer. That memory buffer is output to the client system as quickly as possible, but moderate loss is acceptable. All hardware blits are performed in software instead (since you really aren't using the system's video card at that point).

    Yes, it sounds a lot like X, but without a few major X problems. Video updates are not required. So your windows won't hang on slow networks. Bonus #2 is that a lost connection doesn't have to kill an app. Just reconnect to the server when you get a chance and pick up where you left off.

    I hope I managed to get across the major difference. I have a feeling that I haven't. I have a better explanation in my journal for those who really want to understand my major bitch points for Unix these days. (Even though I'm still a huge Unix advocate these days.)

  • Not supposed to _replace_ X. (Score:2, Interesting)

    by Anonymous Coward
    DirectFB would be great for fast graphics and stuff (as many people have pointed out already).
    No more DRI, et.al, just FB modules in the kernel, and DirectFB with some window manager.

    As far as the annoying whining about how we can't replace X, it's a standard, we need remote display support, blah blah blah, it seems to me that developing an X server that runs through DirectFB is the obvious solution. D'uh?

  • Jim Gettys on X vs. GtkFB and QtE (Score:3, Interesting)

    by Anonymous Coward on Tuesday October 23, 2001 @11:02AM (#2465998)
    It's so nice to see the ignorant Slashdot hordes rallying around the "X sucks!" flag. Here is what someone who actually knows what he's talking about has to say: (from http://www.linuxpower.org/display.php?id=211)

    Jim: No, I believe very strongly that either GTK+fb or QtE are dead
    ends. Our experience in the market (beyond the hacker community) is
    that the major attraction is the ability to share with little or no
    hassle applications written for the desktop: while the applications
    may need reworking to deal with the screen size and touchscreen, there
    are many applications not written for GNOME (or KDE).

    Network transparency is worth a lot in PDA's such as an iPAQ: it is
    really a full fledged networked computer in your hand, which can take
    advantage of other displays, keyboards, etc. in the user's environment
    when convenient. If I have a lot of text to enter, I don't want to use
    a touch-screen unless I must, and I don't want to have to build two
    applications, the way Palm or WinCE does. Others will experimentally
    determine that frame buffer based environments are a waste of time,
    but we won't...

    At CRL (Cambridge Research Laboratory), we are working on the Mercury
    project for pervasive computing. With the advent of high speed
    (wireless) network connections and large (currently 1 gigabyte)
    storage devices like the IBM microdrive, we foresee an environment in
    which you will want to take advantage of the computing environment
    around you, including keyboard, mice, projectors, and servers of all
    sorts. Note that the ability of an application to interact with
    desktops in your network environment is therefore vital, and sometimes
    at levels beyond file and web sharing. Most of what you hear about X
    being too big are from people who know little or nothing about the
    topic. After all, we wrote X Version 11 on 2 megabyte VAX 11/750's:
    iPAQs have 16 or 32 times that much RAM, and a CPU 200 times faster
    (for integer operations).

    Keith Packard, in his TinyX server using his new frame buffer code,
    has reduced the X server to 500-700K bytes of code (depending on
    whether you want his new render extension for anti-aliased text and
    graphics). Most of the perception of bloat is caused by how Linux
    reports memory. An X server maps the display card into its address
    space, and on current graphics cards this can easily be 8, 16, 32 or
    even 64 megabytes of address space (for the frame buffer and registers
    of the display). Naive people look at "ps" or "top" and draw the wrong
    conclusion. Clients may be asking the X server to preserve pixmaps on
    their behalf (which should really be charged to the client, but it
    shows up in the X server). So, for example the RSS size on my iPAQ is
    2.2 megabytes when running Familiar, with backing store and save
    unders still enabled (arguably, on a device like an iPAQ, I should
    disable them, which would further reduce the RAM footprint).

    I recently completed work to remove the dependency on Xt, Xaw, and Xmu
    that many of the little X utilities had accretted over the years: this
    saves 1.1 megabytes of code on a device like the iPAQ (presuming no
    user application wants/needs Xt, which is easy to arrange). These
    changes have just been checked into XFree86.

    The remaining work is to put Xlib on a diet. There is about .5
    megabytes of code and static data that has accumulated since Xlib left
    my hands that few applications and toolkits use (the CMS and
    Internationalization parts of Xlib). These are either never used
    (CMS), or only used by Motif (which few Linux applications care
    about). By making CMS and the I18N parts of Xlib dynamically loaded
    libraries, we can avoid breaking binary compatibility, but allow PDA
    users who don't need them (essentially everyone) to avoid the waste by
    not loaded those libraries. John McClintock has patches for the CMS
    changes which I hope to look at soon, and the I18N work is straight
    forward.

    Keith and I believe that a basic X environment will end up a bit over
    one megabyte of code, when this is done, while preserving complete
    compatibility (a full X implementation).The replacements for X don't
    come free either (they also have to have frame buffer code, window
    operations, etc.). The true cost of network transparency is well under
    a megabyte, IMHO. At the current cost of RAM, it's not much cost, even
    on low end PDA's... We could make things yet smaller, but we'd then
    be sacrificing some compatibility, which, while reasonable, is less
    desirable, as knowing your application should "just work" is worth a
    lot. So I see either QtE or GTK+fb as dead-ends, interesting for a
    short while on the smallest devices, but will be just a passing
    footnote in history.
    • Jim and Keith do a good job and this is an interesting quote (that I have of course read before), but I think the /. readers should have some more numbers to compare. The DirectFB library has less than 140 KB of code size. Depending on the usage, a few modules will be loaded for input devices, the gfx card's hardware acceleration, image and font loading, but DirectFB's codesize will normally not extend 200kB while the X developers are trying hard to get close to the 1MB limit.

      Of course this doesn't matter much for the desktop, but it does matter if you are developing for the embedded market where the costs for RAM and CPU decide if a product has a chance on the market.Another problem with X we faced is that certain features like true alpha channel and color keying are simply not available. These are absolutely needed when developing software for digital TV. DirectFB not only replaces X for us, it gives us a whole lot more X can not (yet) do. It was meant as a replacement for X on settop boxes, not primarily as a replacement for X on your desktop.

  • Don't know if this is it, though it sounds good... (Score:3, Interesting)

    by uradu ( 10768 ) on Tuesday October 23, 2001 @11:11AM (#2466053)
    but something needs to be done about X. I have a very mainstream video card (TNT2), and under Windows it flies for 2D work (1600x1200x32)--full window moving, resizing, scrolling etc are perceptually instantaneous. This same card under KDE 2.2.1--using what appears to be a fairly well supported XFree86 4 server, at the same resolution and color depth--feels roughly like an unaccelerated SVGA driver under Windows, maybe a bit better. Many drawing operations become visible under heavy graphic load, such as when moving windows above other busy windows that need to be redrawn. Resizing windows feels sluggish, scrolling web pages and such feels sluggish etc. We'te not talking 1990-slowness, but in a world where graphic lag of any kind is essentially a thing of the past, this is very noticeable.

    Maybe it's not all due to X, who knows. But dragging around baggage beneficial to only a portion of users (that seems to be getting smaller with a growing Linux user base) almost seems unfair. If I spend most of the day in front of the framebuffer, with only occasional remoting of the display, I'd prefer to have the fastest possible performance during that majority of time, and would in exchange accept worse performance during remoting. That's essentially what happens with VNC on Windows right now. And I know we can do better than that, because Windows has notoriously few graphic hooks, and any new display system could easily improve on that without giving up performance in spades like X.
    • But dragging around baggage beneficial to only a portion of users (that seems to be getting smaller with a growing Linux user base) almost seems unfair.

      Ah, the tyranny of the majority rears its ugly head, even here in the land of the free. We are more numerous so let's vote on everything. That way we get to rule while pretending to be fair. Let's dump all those old bearded Unix types who made Linux into the premier server and workstation platform. We don't want workstations or servers, we want gaming platforms. We don't want Linux to replace Win2K, we want it to replace the X Box.
      • I think you've been watching too much CNN lately <g>. I've noticed that the benefits of X are extolled suspiciously often within the context of servers and remote administration. May I just observe that most serious admins shun graphical tools for the command line anyway? I've seen very few admins attach their display to a remote server for anything, yet most of them live in telnet. I dare say that telnet fulfills most of the duties X is accused of for these kinds of uses. Most of the X apps that would work comfortably remotely over extended periods probably take minimal advantage of a GUI anyway and would likely work just as well in text mode.
  • I've lately been looking at the fb support in the kernel, and unless I'm missing something, the majority of graphics cards are not yet supported. Most cards can just use the VESA support, but it does not currently allow for changes in refresh rate and won't be as fast as a driver written for a certain card. So are there drivers planned for FB?
  • I'm sure there will be a back-end for X at some point. When that happens, I'll check DirectFB out.

    The UNIX-haters link was funny. For those of you who might have taken it seriously, just don't bother. It's a skewed version of history mixed with a lot of personal bile. I'm particularly amused that he chose to call it "X-Windows", and insisted the publisher use that form because it would "piss off" the X folks. The reason he says this is because the X Consortium goes out of its way to point out that "X-Windows" is an encumbered term, so folks are supposed to say "X" or "The X Window System". Nutball. Nuff said.
  • This sounds like it would be a *HUGE* step forward for the *NIX community as a whole. Unfortunately, it will probably fail because our community is so stubborn. If X is so great how come Apple chose to go their own way and implement Aqua? X certainly would seem more advantageous for them...just port X-Free and you've got thousands applications instantly supported on OS X...the problem is that it takes a lot of hard work to make X pretty. Look at KDE, Enlightenment, and Gnome. These projects have taken years trying to make a square round when reinventing the wheel would have been much easier.

    If Linux is ever to be a player on the desktop, we will have to abandon X. X and DirectFB are not mutually exclusive and there should be a relatively painless transition. X just doesn't make sense anymore for a PC dominated world. When was the last time any of you used a dumb terminal? I've never used X on anything other than PCs and I'm sure that most of my generation can say the same.

    In short we need a new king for a new generation.

  • NO! Why does everyone think that transparency is the coolest thing ever? I admit it look vaguely cool in screenshots occasionally (although the one linked from the article look horrible to me), I've always found it to be a functional nightmare when I'm actually using it. I put that window on top of the other one for a REASON!

    I mean, really. The screenshot linked to is just awful! Which window's on top? Can I click on "Expand All?" Boo!

    But the software itself looks keen . . .

  • The problems with X (Score:3, Insightful)

    by iabervon ( 1971 ) on Tuesday October 23, 2001 @04:44PM (#2468886) Homepage Journal
    1) It's networked. People don't use this any more, mostly. If they do, it's via ssh, which doesn't use the network features of X anyway. X ought to just specify talking to a local server, which may be a proxy over ssh.

    2) Its core protocol is missing a ton of features that program want. For example, nobody on the team knew how to do splines, so they left them out. Splines still aren't really supported, and won't be supported any time soon in the core protocol.

    3) It's too extensive. It is generally implemented as a set of drivers, library, network server, resource manager, plus windowing system. Some of those features ought to be separate. In particular, splitting off the drivers (as well as implementations of operations the actual card doesn't support) from the windowing system would save a lot of hassles.

    I think a layer for doing graphics under the level of the X server would be better. The main problem is that XFree86 has really good free drivers, which would be a shame to reimplement, but they are all for the X API.

    There are some cases where you don't actually want the main features of X, so it would be good to provide a more fundamental graphics layer to programs that want it.

Slashdot Top Deals

Ummm, well, OK. The network's the network, the computer's the computer. Sorry for the confusion. -- Sun Microsystems

Close