Slashdot Mirror
DirectFB: A New Linux Graphics Standard?
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?"
(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.
These sigs are more interesting tha
The company's name is "convergence integrated media GmbH", and we actually own the trademark in Europe.
So there's no risk that they sue us...
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 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!
This was originally designed for their DVB/Tivo apps I believe, they needed an on screen graphics package that included alpha channels so it wouldn't obscure the MPEG2 stream underneath.
:)
If you have a Sony TV you should know how pretty alpha channels are
There's a standard X extension (?) called LBX that comes with XFree86 and others. Check out the LBX Mini-HOWTO if you are interested.
Cheers //Johan
Installed the Bubblemon yet?
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
Why don't you visit the sites referenced by the links sometime? They HAVE an X server that sits on top of DirectFB- think of X as being merely a protocol, once you've done that, it matters little how you render to the screen or accept inputs (This is what DirectFB does...) so long as the implementation you're using works at least as well as any others.
Having said this, they're not quite there yet, but it's coming along nicely and is quite promising.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
/. blurb- they HAVE an X server for this and are advancing it as well because for most things, it's better to use X.
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
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
Outdoor digital photography, mostly in New Engl
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)
Q: When I specify SDL_FULLSCREEN in X11, the screen goes black and my window is centered in the middle, instead of covering the whole screen!
A:
X needs to be able to switch to the desired resolution. For this to work, you need to have the resolution listed in the 'Modes' line in your XFree86Config file (and your Monitor must support it). SDL does not currently support changing resolutions on X servers that do not support the XVidMode extension.
The following example is taken from my config for XFree86-4.0.1, but 3.3.x is similiar. Note that if your monitor isn't capable of using these video modes, the X server will drop these modes from the list of available video modes.
Example:
Section "Screen"
Identifier "Screen 1"
Device "3dfx"
Monitor "Samsung LCD"
DefaultDepth 16
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480" "320x240"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Note the different entries for 8 & 16 bit screendepth. I.e. the 320x240 resolution is *not* available when X is started with 16bit depth (the default).
To test these entries, restart X after you modified XF86Config and press ctrl-alt-plus and ctrl-alt-minus to cycle through the resolutions.
I just don't get it. Why do people hate X? It's a fairly powerful system. There are implementations with excellent 2d and 3d hardware acceleration.
It does *not* use up "tons of RAM", as some people who don't understand the X architecture like to claim. If you see the X server using lots of RAM in top or the like, there are two very good reasons. (a) device mappings. Top counts this towards the total, but it isn't "real" physical memory being eaten. Have a 32MB video card? Guess why X looks 32MB bigger than it should?
(b) X stores pixmaps locally. This is why X *client* programs use less RAM than their Windows counterparts. One of the two (client or server) *has* to store any pixmap that's going on the screen. For speed over a network, it's much more intelligent for the X server to do so, since the pixmap will probably be drawn many times. So the client doesn't have to store its own copy...but it makes X look "bloated" because it's using some RAM itself to take load off the client programs. The overwhelming majority of RAM that X uses goes to this. If you're using Enlightenment with a pixmap GTK theme, the reason X is taking up more memory is because the client programs *aren't*.
The only real issue people have with X performance is that between the time an application wants to draw to the screen and the time the drawing happens, a context switch needs to occur. This is why the XFree folks came up with DGA, which avoids exactly this -- if you're just playing a game on the local computer, X imposes no overhead.
X does some damn cool things that Windows and friends will never do. Obviously, you can run programs over a network (without incredibly inefficient hacks like vnc). However, on a copy of XFree, hitting control-meta-kp or control-meta-kp- will let you switch resolutions, zooming in on something and letting you show stuff to people across the room (I use this a lot in my dorm room)
There are a few things that I don't like about X. X has a very sophisticated color management scheme, allowing you to output to just about any type of X server, but which can get complicated if you just want to draw something to the screen on your x86 box on XFree. That's why almost no one uses raw Xlib (X's own interface) and uses stuff like SDL or GTK, which handles the nasty details for you, and just lets you do your work.
XFree supports multiple monitors, desktops larger than your monitor, hardware alpha blending, shaped windows...
It's true that existing GUI "E-Z X configuration tools" haven't impressed me much, so you do have to maybe do a bit of poking to tweak out your configuration exactly the way you want it...but that's also true with most operating systems.
Oh, and Xlib doesn't natively support detatching windows from one X server and reattaching to another. I suppose this could be an issue, but since proposed replacements to X mostly don't do this *either* and since toolkits built on top of Xlib *can* do this...
Of course, you don't *have* to run an X server if you just want a console box...this guy doesn't run X.
For GUI systems, though, X is where it's at.
Also, it sure is purty.
We really like to support newer cards like GeForce or ATI Radeon. The problem is to get enough documentation to implement all the features supported by DirectFB. Taking X driver source does not much help, because X drivers support only the basic operations.
try out dxpc. its a X proxy that does compression.
with dxpc using netscape over a slow (ISDN) link becomes at least 20 times faster in my experience...
Everyone seems to be going on about how slow XFree86 is, and how we need a direct framebuffer layer bla bla bla... well on my box, Quake3 runs about 20% faster in Linux than it does in Windows.
Hardware: ASUS-CUV4X (via chipset), p3 866, 390mb RAM, Geforce256+32mb
Linux: Redhat 6.1 upgraded to Xf86-4.02, kernel 2.4.6, NVidia-1.0-1541
Windows: WinME with latest NV drivers, and all tweaks. (Was win2k and that was even slower)
Nothing special about that system, and I don't have any speed problems. Admitadly X does take up a fair bit Of hard drive, and about 4 megs of ram, but its I could scale that down pretty easily