Slashdot Mirror
DRI Comes to DirectFB
Pivot writes "To further heat up the discussion about the future of the graphical desktop on open source OSes: Now the DirectFB project works with DRI!. Screenshots are available. I guess what is lacking now is only XAA driver support, or native drivers for your favourite graphic card." We've mentioned DirectFB before.
Most modern consumer hardware *does* work in Linux. Stop trolling the threads! What do you guys do, just sit here and wait for these to pop up, and paste in some macro or something? GUI speed is not lacking in Linux. If you have a problem, it's because you are using a frickin' framebuffer mode. How many times do we have to tell you trolls this?
1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.
2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.
3) Window transparency is overrated. Window double buffering is not.
4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.
5) Half the comments in this thread about XFree will be misinformed ;)
Huh? NVIDIA is the first company which provided professional quality Linux drivers. Because of this many companies have moved to the Linux. Isn't this enough for your acceptance?
NVIDIA cards work very nicely with every XFree 4.x version.
If you are complaining about closed source drivers, then I have a bad news for you. There isn't a SINGLE company which releases specs for open-source developers for the new hardware.
Matrox Parhelia 2D driver is closed source, ATI has stopped DRI funding and DRI drivers won't work with new R300 and R350 (Radeon 9500, 9600, 9700 and 9800) cards.
That's why adding 3D support to DirectFB seems to be quite pointless. I doubt that ATI, NVIDIA or Matrox will port they drivers to DirectFB.
That almost made sense until you started ranting about Gnome being obsolete.
I don't use KDE or Gnome, but I do think that the choice is a good thing.
"I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20?"
Multiply that by 1 million and you'll get 1.000.000 in 20.000.000.
Don't mark something down as "useless" bloat just because only what seems to be a minority in percentages use it.
Even if only 1% use network transparency, if there are 500.000.000 computer users then there are still 5 million people who need network transparency!
Why is the parent modded as flamebait?
/. article demonstrates precisely the downsides of closed hardware (implied from closed source drivers), ie the open source community cant hack on them and do new things with them.
The post is 100% correct, this
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
To prevent uninformed comments about X:
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
Look here for an explanation of what Unix domain sockets are. They have nothing to do with networking and are the most efficient form of IPC on Linux. As a bonus, you can write code which uses either AF_UNIX sockets or AF_INET (TCP/IP) sockets seamlessly--but AF_UNIX sockets still have nothing to do with networking. Got it?
"Crowd: X is bloated
i endly-Windows-XP has millions of code too.
o u-no-matter-how-uninformed-we-are"-zealot.
X DefenderS: X is not bloated it is just everything else on top of X"
Proof: use twm/fvwm/IceWM/BlackBox/Xfce. Behold the speed.
GNOME and KDE are slow, X is not.
"Crowd: Network Transparency is a hog
X Defenders:No it isn't there is just not a single app which does it right,"
Proof: try running xterm remotely. Now, do the same thing with Konsole and Gnome-terminal (2.x). Behold the difference in speed.
It is also important to know that XFree86 does not use TCP/IP locally! Pixmaps are transferred using shared memory. Other (significantly smaller) data are transferred using a Unix Domain Socket, which is just as fast as shared memory (at least on Linux).
"Crowd: X is slow
X Defenders: No it isn't run two X servers side by side and see that they have comparable speed"
I've never heard of an X defender say such a stupid thing. Obviously you made this up. That makes you a liar.
Anyway, it can be proven that X is not slow. Run the x11perf benchmarking utility:
x11perf -rect500
x11perf -repeat 3 -shmput500
On my system (ATI Rage 128, Athlon 1,4 Ghz), XFree86 can:
- Draw 1190 500x500 rectangles per second (1190 fps).
- Blit 210 500x500 square images per second (210 fps).
- Scroll 530 500x500 pixels per second (530 fps).
There, I have numbers. Now show me your numbers that X is slow.
However, if x11perf *does* report significantly lower framerates on your machine, then that only proofs that the main bottleneck is drivers, not X itself.
Crowd: X is bloatware
X Defenders: No every single line of the 7 million lines of code is needed, even the code from the flight sim"
Lots of code does not equal bloat. I'm sure you already know that, but you only say this to troll.
The oh-so-high-performance-and-oh-so-consitent-and-fr
"Crowd: Look there is something better and faster
X Defenders: We don't need that we have network transparency (which implicietly is unusable over slower lines)"
Except DirectFB is not better and faster. Hello, there's more about a windowing system than just drawing pictures!
- Even with this OpenGL/DRI backend, DirectFB still doesn't support nearly as many video cards as XFree86.
- What about inter-process communication? Like drag & drop or event notification?
- Where's the compatibility? You can't expect everybody to rewrite their app for DirectFB. Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?
You are just another "we-are-the-biggest-group-so-we-are-better-than-y
First of X is not that bloated - have a look at TinyX (part of the XFree tree), its 868 kilobytes in size and is currently using about 5.9MB of RAM on my Ipaq (868KB for the exe, 2MB for libraries and just 2.6MB for data - and thats with a few apps open too).
/still/ be done somewhere if one wishes to actually have more than one app displaying to that framebuffer, ie arbitration. If you look at toolkits designed for plain fb's, eg QtEmbedded, they have a good bit of code in them to allow for arbitration between different apps for access to the framebuffer (and hey, now you need scheduling code too!). Iirc, there was an interview with one of the guys who was involved early on with the Berlin project, and he said that by time they had all the things needed to allow apps to work together on displays they werent far off the size of an X server anyway.
People who say X is bloated are either ignorant or liers.
Also, X provides things which plain framebuffers do not which must
Also, often when people blame X for bloat they're blaming the wrong thing. They see X taking up 80MB on their desktop and go "oh bloated" - but in all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!
I use Friend/Foe + mod-point modifiers as a karma/reputation system.