The first, very-alpha, release of the Qt library onDirectFB is now available for testing! A lot of things still have to be
implemented, so please don't expect to be able to run Konqueror on DirectFB
(yet). You can find screenshots and a link to the source here.

No, he doesn't mean XDirectFB. Since XDirectFB is a layer on top of DirectFB, the hardware support is just as terrible. As in, you basically need a matrox card to get it to work (and those of us with more obscure cards like savages are of source SOL and always will be).

As for drivers, the lack of good accelerated drivers frustrates me too. I have an NVidia card, and it works pretty nicely under DirectFB, just isn't accelerated. I haven't been able to try a Savage card, but their status page ( http://www.directfb.org/modules.xml ) shows them as being "70%" supported, whatever that means (whereas NVidia only has 10%). Probably now that there are open source Savage drivers that will improve.

he said "And any modern windowing system better be network transparent". I was just mentioning that this network transparency doesnt need to be mated to the system like it is in XFree86. XDirectFB allows for most XF86 supported protocols to be used.

As for hardware support, it could use some work. I also mention the retardedness of the 2.6/2.5 framebuffer in another post. It is truely horrid...

(Especially with linux 2.6 soonish to be stable and released and DirectFB not working under it. But this isnt a DirectFB issue, the linux 2.5 and 2.6 framebuffers are retarded and have had their balls removed.)

DirectFB in itself is not a windowing system. Basic windowing controls have been hacked on recently(?) and involve meta keys, and work has been done with the (non-working for me) multi-server core that allows you to run more than one DirectFB app.

Yes. You heard right. DirectFB normally limits you to one app at a time unless you patch your kernel with fusion MPI support and even then multi-server support is far from gurenteed to work.

DirectFB isnt aiming to be X here. Still, this is a beautiful thing to hear of. Especially for embedded linux developers who have the rom/ram space to burn I would think. Or console enthusiasts who want to not start X when they want to use a gui web browser quick quick (that isnt uglyish like links).

I'm still waiting for a 1.0 release of XDirectFB. the rc4 worked for me but rc5 is horrible. *sigh* XDirectFB feels so nice and smooth when it works properly. Too bad it doesnt have xv or gl support yet. Most people think XDirectFB and say "why do I want translucency, this is a toy" when the XDFB X server has other perks than just this. bah.

I've visited the website but can't figure it out really.
Is it something like Microsoft's DirectX?
The website says something about hardware.
But is it realistic that graphic cards will support this?
I don't think they will create graphic cards which run on Linux/Un*x
only.

No, compared to XFree86 (_without_ using a driver with support for hardware acceleration), DirectFB is way faster.

The bad thing is that DirectFB does only have a few drivers available and there's no (good) NVIDIA driver :(

So yes, on NVIDIA cards (and many others, but I'm just picking a good example) it's slower, but you'll still notice that DirectFB is faster than XFree86 (everything feels more smooth/fluent, like Windows.. or even better actually)

/me hopes everyone will switch to DFB in the next 2 years.. (including NVIDIA please)

Come on, that's completely unrealistic. Who will port all those thousands of applications and write dozens of drivers? And why should anyone do it? Because there are a few good drivers for outdated cards? It's unlikely that DFB offers any useful advantages. But it definitely has disadvantages, like the lack of network transparency.

Are you sure? While the X protocol might be far away from being perfect it's still a lot more usable than any vnc I've tried. Especially on fast LAN connections. Working with an X session is close to working locally. VNC doesn't even come close.

What about just exporting single applications. I don't think something like that will be possible without much weirdness like rendering the app virtually on the server and transfering the image. Otherwise you are close to X again.

I think DirectFB is a great idea and it is useful for many things, especially for embedded devices etc. It would be a tragic loss for UNIX/Linux to get rid of X11 though.

It would be easier to make the XFree scheduler smarter, and the toolkits faster, as that is often what causes perceived slowness on screen. The actual speed of the underlying graphics system is rarely a problem.

Perhaps it's easier coding-wise, but with the current 3 or 4 active people behind the project (doing 2 bugfixes a day and not adding needed features) I don't see that happening between now and the next 10 years.

>> and the toolkits faster

The toolkits are already faster (and especially smoother) when using DirectFB.

>> as that is often what causes perceived slowness on screen

True, but the fact that it's easier to make slow and unresponsive programs using XFree86 (quite hard to use API - even toolkits are making many faults) than using DirectFB is also something to think about...

The problem is not the X protocol, but XFree.
It is a hungry beast, nothing else.
It should be completely *rewriten* to have less latency.
Many parts(hopefully drivers) can be reused, but the core is rotten.
There are 2 kinds of speed, throughput and latency.
For most users, latency (reaction speed) is more important than throughput.
BeOS and QNX both are capable of having a responsive (multithreaded) userland graphics system, so why can't unix and linux?

I'm pretty sure neither BeOS nor QNX actually have a fully multithreaded graphics layer, as at some point you need to have a mutex around the framebuffer. Maybe parts are multithreaded, I dunno.

Anyway, the main problem with XFree is like I said a matter of scheduling and asynchronity, especially with respect to window managers/apps. Like the Linux kernels responsiveness can be improved with VM/scheduler tweaks, so can XFree.

What I don't get is why all the Windows users want Network Transparency and Microsoft is trying to put something similar in its windowing system, and all us linux users have it and want to get rid of it ?? I think you people are crazy. I use network transparency every day. If you actually tried it you would too. It's nice being at work on a linux box and being able to open your home email client over the internet. Its not the network transparency that makes X slow. There is now need to get rid of it.

Not to mention that a kilobyte is only a 1000 bytes, you would need a kibibyte (KiB) to store 1024 bytes.

On the topic of network transparancy, I (for one) would rather live without alpha blending (transparancy) - althought it's on its way in XFree86 - than live without newtork transparancy (although I rarely use it).

BTW to those who think that X11 causes poor performance, try comparing AccelleratedX with XFree86 and then decide whether it is X11's or XFree86's fault.

BTW(2) WRT to the directfb screenshots, is directfb responsible for the transparency of Anna Falchi's top? If it is I might choose the alpha blending over network transparency :-)

"95% of the users don't need and/or don't use that feature, why should the other 5% dictate those users what they should use and make them use software that's suffering from bitrot?"

1) 95% of users don't need and/or don't use KDE, but some version of Windows instead. Maybe we should just kill off the KDE project and all use Windows.

2) 95% of the time I drive, there are only one or two occupants in the automobile, which is a complete waste of the back seat. 95% of the time I drive, the trunk is empty, which is a complete waste of space. I would be much more efficient if I drove a motorcycle instead. Of course, it would then be damned inconvenient when I have more than one extra passenger, damned inconvenient when I need to go shopping for something that won't strap on the back, and damned invconvenient when I get a flat tire and realize that all my emergency tools were in the trunk of the car I sold because it was such a waste.

3) Perhaps 95% of Linux users don't need network transparency, but I will safely assert that 25% to 50% of UNIX users indeed use it on a regular basis. Maybe your vision of vision of a workstation is to be some sort of Xbox clone, used in the home by a single user to play games. But most of us use workstations in a multiuser networked environment to get our work done. A workstation without network transparency would make that work a heck of a lot harder to get done.

4) XFree86 is not suffering from bitrot. More people use network transparency than use Xinerama. But I don't see any hue and cry to get rid of Xinerama (or other multihead support).

5) A million people have already said this, but you haven't been listening. It seems you're attention has been wavering. So get this through your head, NETWORK TRANSPARENCY DOESN'T COST YOU ANYTHING IF YOU DON'T USE IT!

Actually, network transparency DOES cost because it still has to pass through X's network layer. If you're running on a local machine, it doesn't cost *as much* as X over IP over ethernet, but calls to the X libraries still have to be converted to the X protocol, and passed though the network layer, transmitted over a Unix socket, recieved by the X server, and decoded.

You always need some protocol between the applications and the process/drivers that is responsible for drawing, unless you want to give the applications direct access to the graphics hardware. And even if they had direct access you would need some protocol for locking (because affordable hardware doesn't allow more than one driver to use it at a time).

There are, of course, different ways to implement this protocol. You can pass messages over unix domain sockets, which is the fastest IPC mechanism for messages on Linux, and what X11 does. Or you can put the driver into the kernel and define a few dozens ioctls. They are just another form of protocol. But whatever you do, you need some protocol.