The first, very-alpha, release of the Qt library on
DirectFB 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.
Dot Categories:
Comments
At least!
This is the beginning....XFree,react or die!
ROTFL :)
I don't see DirectFB going anywhere soon. Hardware support is still not nearly as good as XFree86. And any modern windowing system better be network transparent.
You mean like XDirectFB? Or are you assuming that the misc X network protocols cannot be implemented without an X server that also directly accesses hardware?
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).
I think LV was addressing the network transparency point.
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...
I somehow doubt QT on DirectFB will kill XFree.
(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.
directFB can use OpenGL for hardware acceleration. Most graphic cards support OpenGL. they only problem is the lack of drivers.
So can X. DirectFB is just an abstraction layer over the framebuffer device, but is normally slower (yes! slower!) than XFree, unless you use matrox G series of cards.
It is slower. Now!
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.
> Who will port all those thousands of applications
Rather, porting toolkits such as Qt, gtk, and Motif is better.
KDE itself has some X11-specific code, but various people are working on free-ing KDE from it (first the kdenox stuff, then the QWS stuff, and then the port of KDE to Qt/Mac for MacOSX without X11)
Drivers are a good point however. In terms of network transparency, I think things like VNC/rfb/rdc/timbuktu/citrix are the wave of the future, not X-type 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 a tragic loss for UNIX/Linux to get rid of X11 though.
It's GNU/Linux, not UNIX/Linux.
And we all know (you do now that, right?) that "GNU's Not Unix".
X11 belongs to the UNIX platform, not GNU.
Last time I checked, not all software on my computer was part of the GNU project, so, it's not GNU/Linux, it's "Linux and associated open-source software".
Last time I checked, not all software on my computer was part of the Linux kernel.
So, we shouldn't call it Linux either.
Perhaps the change the name of the OS should be changed into GLKGQGXFB?
:) I think he meant Unix AND Linux (Unix AND GNU/Linux)
I may be stupid, but I'm not thát stupid ;)
That's definitely the way I read it. I commonly use the term "UNIX and Linux", so seeing "UNIX/Linux" meant the same to me.
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.
>> It would be easier to make the XFree scheduler smarter,
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...
http://xcb.wiki.cs.pdx.edu/ is trying to make a Xlib replacement with lower latency.
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.
>> Who will port all those thousands of applications and write dozens of drivers?
Do you really use any of those old apps?
(I certainly don't, I'm only using cli, gtk/gnome and qt/kde apps)
Anyway, should be possible to write some wrapper for those apps.
(XFree86 may suck, but it does have a stable ABI so that shouldn't be the problem I think)
>> And why should anyone do it?
To get rid of that old cruft called XFree86 and the (mostly) backseat developers behind the project.
>> But it definitely has disadvantages, like the lack of 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?
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.
Perhaps I'm not geeky enough, but usually when I leave home I switch down the power to my system..
>> 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 are 3 options for that:
- Redirect your email to an address at work
- Use webmail
- Don't view any email from your home address at all, you're at work to work, not to view your private email
The former two are faster than opening a connection to your home box and you'll even save some money by powering down your home system when you're away.
I'm not just talking about email. It could be anything. I'm just saying its a nice feature to have and it shouldn't be removed.
Network transparency is pretty useful for thin clients.
*Many* KDE apps, especially those that are system near or use fancy graphics, use Xlib directly. I suspect that with other toolkits it's not different.
>> 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?<<
Because everybody uses a different 95%. That's why software that does not have 100% will not succeed.
The GTK+ DirectFB port has existed for ages, you can run most gnome/gtk applications with a simple recompile.
They *don't* suffer from network transparency. On a modern desktop system, the overhead produced by a well-designed and optimized network transparent windowing system is perfectly acceptable.
It's not acceptable if you don't have any use for it.
And what are you giong to do with that extra-kilobyte?
Filling it with 1024 characters and 2048 nibbles..
No, you aren't.
Nowadays characters are 16-bit, so you can't put 1024 of them into a kilobyte. Not to mention that AND a pile of nibbles!
The days of characters==bytes passed about two, three years ago.
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 :-)
"Kibibyte" is the silliest name I ever heard.
"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.
There must be a simpler way of doing this.
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.
NVIDIA has said that their Windows/*BSD/Linux drivers share 95% of the code. Thus it wouldn't be a big deal for them to make hardware accelerated drivers for DirectFB.
"No, compared to XFree86 (_without_ using a driver with support for hardware acceleration), DirectFB is way faster."
Does it surprise you that DirectFB with hardware acceleration is faster than XFree86 without hardware acceleration?
And smooth does not always equal fast. Have you ever benchmarked raw drawing speed? How many 640x480 can DirectFB and XFree86 blit per second?
>> Does it surprise you that DirectFB with hardware acceleration is faster than XFree86 without hardware acceleration?
Not really.
>> And smooth does not always equal fast.
Very true.
>> Have you ever benchmarked raw drawing speed? How many 640x480 can DirectFB and XFree86 blit per second?
Please tell me, what's the use of having a fast graphical subsystem if it doesn't feel smooth? (which most users perceive as being slow)
Argh, pressed the reply button too quickly |:(
>> Does it surprise you that DirectFB with hardware acceleration is faster than XFree86 without hardware acceleration?
Not really, but I meant having hardware acceleration disabled for _both_ XFree86 and DirectFB.
DirectFB is faster in that case as well.
Because then at least you can still fix things to make it look smooth. If the raw drawing speed is low then graphics intensive apps like games will hit you hard.
Games are usually using complete different API's..
And it won't be fixed, you know that as good as I do.
(core team, yadda yadda)