Now it is possible to have hardware accelerated OpenGL with DirectFB.
DirectFBGL Goes DRI
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Now it is possible to have hardware accelerated OpenGL with DirectFB.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Oh boy do the screenshots look gorgeous….
Except for the fact that only windowing system that is usable on Linux is X.
And XFREE86 is the bane of Linux Desktop Existance and Advancement. Why can’t the Linux community just embrace a new exciting windowing system for christ’s sake.
XFREE86 isn’t going anywhere, xwin.org ain’t going to save you either, it’s just a forum and a web log for trolls.
Simply – XFREE86 is _JUST TOO OLD_, only a few people understand it internally. While I think old things are great (Like POSIX standards), things like XFREE86 need to be given the bin.
Sure like all things, even DirectFB over time it’ll succumb to extension bloat to deal with requirements that never existed when it was initially created (like X and its DRI, SHM etc extensions), the big issue is we don’t need a windowing system that communicates synchronously because of it’s network based heritage, that can be done as a module, like in DirectFB. What we do need is adoption of latest technologies, like the recent OpenGL composited windowing ‘hack’ for XFREE86 – something that DirectFB has been doing for ages.
I am sadly and rapidly getting disillusioned about this entire situation. XFREE86 is not going anywhere fast – and it ain’t good enough.
And yes. I am a programmer and have been studying the internals of Xfree, but it’s too little too late.
OH BOY!!! Here comes the Xfree86 sucks posts.
I thought this was what XDirectFB was meant to solve…
Your a programmer and you are complaining about extensions? The best thing about XFree is the fact that it is modular.
Nice to see you’re doing something about it Mr Arm Chair programmer. Instead of ranting and raving like a nutter, how about actually put your fingers into gear and do something about it.
Screen shots? What screen shots?
When I go to: http://www.directfb.org/screenshots/ all I see is, “Old Stuff” Where are the current screen shots?
“Screen shots? What screen shots? ”
Just open 1st one, on it You’ll see exlanation, some 3d objects rendered in realtime, and fps counter.
You people are even more lazy than i am ;P
Something is wrong with my vision. Those screenshot look transparent.
Is this OpenGL running on top of DirectFB or DirectFB running on top of OpenGL/DRI (which would be really cool)?
If the later is true this would also solve the driver issue for many 3D cards.
Reading the FAQ I see that GTK+ apps have to be recompiled for DirectFB. Why is that, are there any plans to make DirectFB a binary compartable, drop-in replacement for X? Is there a Qt port?
Is this OpenGL running on top of DirectFB or DirectFB running on top of OpenGL/DRI (which would be really cool)?
DirectFB is running atop OpenGL/DRI.
Reading the FAQ I see that GTK+ apps have to be recompiled for DirectFB. Why is that, are there any plans to make DirectFB a binary compartable, drop-in replacement for X?
Gtk can work directly atop DirectFB. However, for other Toolkits, there’s XDirectFB which implements a rootless X server over DirectFB. Obviously, if you just use DirectFB, it’s preferable not to have to have your apps working through a compatability layer, hence the recompilation of Gtk recommendation.
Is there a Qt port?
I’m pretty sure the answer to that is ‘no’.
what is directfb? what is a framebuffer device? how is it different from the way normal video card drivers work?
is it a newer generalised stanmdard like vga, vesa, … that works will any card?
is it faster/slower than normal video?
i did look at their site to find out but i’m still confused.
[ what is directfb? ]
DirectFB is a an attempt to turn the Linux kernel framebuffer device into a usable windowing system, by providing sane APIs and a fast IPC mechanism to applications.
[ what is a framebuffer device? ]
It’s a video driver that operates in kernel space, from what I’ve read.
[ how is it different from the way normal video card drivers work? ]
Normally the XFree drivers, which run in user space, are used to poke the video card registers.
[ is it a newer generalised stanmdard like vga, vesa, … that works will any card? ]
No, drivers have to be written especially for the Linux framebuffer. Very few cards have good drivers, Matrox G400 is probably the best.
[ is it faster/slower than normal video? ]
This isn’t a good question to ask, as fast/slow is dependant on a lot of things. With equally well written/accelerated drivers, it operates at about the same speed as X I believe. However, everything is composited so you can do transparency/window dragging with tearing. The last one in particular can make things “feel” faster.
Basically DirectFB renders direct to video memory from the apps, with some basic IPC to let apps negotiate amongst themselves. You get window transparency and a few other toys at the expense of network transparency. It’s hardware support is far worse than XFrees.
[ i did look at their site to find out but i’m still confused. ]
Yes, it is rather confusing, it assumes quite a lot of technical knowledge first.
that should have been “window dragging withOUT tearing”
And XFREE86 is the bane of Linux Desktop Existance and Advancement. Why can’t the Linux community just embrace a new exciting windowing system for christ’s sake.
XFREE86 isn’t going anywhere, xwin.org ain’t going to save you either, it’s just a forum and a web log for trolls.
Simply – XFREE86 is _JUST TOO OLD_, only a few people understand it internally. While I think old things are great (Like POSIX standards), things like XFREE86 need to be given the bin.
True, xwin.org have no future. Thay are right out their analysis of the “dictatorial” way of “live” for the open-source projects, and especially the XFree one. But a political analysis is far from sufficient to build something working ;-)))
True for XFree86, this is really obsolete, but moreover true for X, the free of paying releases.
I think this can be extended to the Linus Torvald kernel. This stuff is obsolete too ( but working, and sometimes, very seldom, working well ).
gcc is almost acceptable, even if the binary incompatibility between releases is a definitive drawback.
Very curiously, i begin to believe that only the GNU libraries are valuable. Of course libxml, libc or fileutil are not themselves exciting, but they provide a good, and overall necessary, basis.
The thing which always astounds me, is to see that eventually Linux is working with all this spaghetti design, blending very poor softwares ;-)))
This seems very interesting, however, i couldn’t quite figure out what does DirectFB replaces (if at all).
is it similar to SDL?
does it Replace X?
does it have API compatibility to other library which it can replace?
is it a layer on top (or below) X? (such that all apps use it without recompiling them?)
should apps be just re-compiled while linked to some replacement libs for native DirectFB? should the apps explicitly use DirectFB API (like SDL)?
in general, where is it located in the libs hierarchy?
Hearn,
thanks for the info, I was pretty confused too. One question tho: if DirectFB is running in “kernel space” instead of “user space,” shouldn’t it be faster because…well, just because? I don’t even have enough know how to even ask the damn question…sheesh…
Why the big hurrah for window transparency? It looks ‘techy’ and all but it makes things a lot harder to read.
Yeah it does look hard to read now, but there are theories that make it easier to read. I’d share them but they’re not my idea. I’m not enitirely convinced the ideas are workable, but it would be interesting to see it implemeneted anyway.
I think the main thing about transparency is the wow factor, even if you have most stuff fully visable, when moving/resize/minimize etc, these effects can be used to help make the enviroment look more impressive.
If we have the graphics card hardware to do it anyway, why not?
It isn’t a layer on top of or under X, thouigh there is an X server that uses it (I’m using it right now, in fact!). It has a naitive port of GTK+, and, unlike SVGALib and allegro, multiple DirectFB apps can run at once. It has a built-in windowing stack, it uses any available hardware acceleration (Though Matrox cards have the best support right now), with software fallbacks for whatever the current card/driver doesn’t accelerate (Think about it like a linux version of Apple’s Quartz Extreme, only without using Display PS/PDF). It’s also small, low on system requirements (Any card that the linux framebuffer device supports will work, at least in software mode), it’s fast, even in software mode, and it even has an experimental SDL backend, so it can work on the various *BSDs.
These are the reasons my little tiny OS project, ClassicOS ( http://classic-os.sf.net ), is using it instead of X. It may not be for everyone, but it works just fine for me. Your mileage may vary.
@Alex (The Original)
The didn’t set the width and hight for the table with the screenshots( td valign=”” colspan=”” width=”” ).
So my IE renders them 1×1 pixels in size XD
Just click at the smal dots.
The one major advantage XFree86 had over any other project (DirectFB, Berlin, PicoGUI etc.) was it’s support of hardware-accelerated 3D.
Presumably, since DirectFB is using the DRI, that any card with a XF86 DRI driver can be used with it.
I had DirectFB/XDirectFB running quite happily on one of my machines, but the CPU load was extremely high compared to XFree 4.x. It had an ATI card (not a Radeon or anything) so its quite likely there wasn’t much acceleration available for it.
I believe GTK+ has a DirectFB GDK backend, but it is limited to running a single application at a time – excellent for embedded applications, and games as well (though you don;t see many GTK games worth playing), but not really ideal for a general purpose desktop.
The true transparency in XDirectFB is nice, but ‘standard’ XFree86 is a much better product for actually getting stuff done with your PC at the moment. There were some apps that refused to work properly on XDirectFB and I experienced some crashes. Still, an excellent initial implementation of an alternative GUI layer that keeps X application compatibility.
Keep it up, DirectFB team
>I believe GTK+ has a DirectFB GDK backend, but it is
>limited to running a single application at a time – excellent
>for embedded applications, and games as well
>(though you don;t see many GTK games worth playing),
>but not really ideal for a general purpose desktop.
Nope, you can use more than one GTK+ app at the same time. I point you to this screenshot: http://www.directfb.org/screenshots/gimp-multi.png . This is the GIMP running on the multi-app core. Those plugins are separate processes. You could re-compile any GTK app that doesn’t use any naitive X code, and it would probably run fine. And if it uses X code, you can just start XDirectFB, and use X apps On that, without having to quit your currently running DirectFB apps.
Addendum: What you mean is the naitive LinuxFB backend. That’s not this at all. The FB backend that comes woth a standard GTK tarball only runs one app at a time. This is a whole other animal.
Having transparent windows and elements is about increasing per-pixel information density and making the interface more visible. Granted, with several layers and heavy overlapping it makes the GUI harder to read, but tastefully done you can make things less obtrusive and more friendly (like transparent dialogs windows that let you see the information below without having to move the dialog window).
The problem that transparent windows help is projecting a 3d workspace (overlapping windows) on a 2d display.
its opengl running over directfb… just an opengl app rendering with directfb, not directfb being rendered by opengl………………………………………………………. …………………….word
Is there a framerate limiter? If not, there should be one, so that some of the CPU power would be available for other tasks as well (in the screenshot there was 98,7% of the CPU power used by DirectFB). The FPS rate should be user configurable and there should also be some benchmarking program to set the optimal FPS rate for the system.
And it would be very cool to have ability to use the “Tranformation & Lightning” -engine to draw the whole screen. T&L is math processor that exist in almost every gfx-card since Nvidia’s (original) GeForce256, its purpose is to leave more time for CPU to do other tasks.
the eariler poster seems happy abput directfb rendering opengl (not the pother way round)… why?
surely if your hardware does opengl you want to offload the work into it?
again – i could be seriously misled here…
t
No, at the end of the day somehow your graphics commands have to get to the graphics card, the apps still run in user space.
What happens with DirectFB is that the apps draw directly into video memory, and the card composits them (as far as I know, I’m a bit out of my depth here). There is less overhead as it doesn’t go via a middle-man process (the X server), but in reality most apps spend 99% of their time waiting for events anyway, so for desktop apps the speedup gained from eliminating the X server is not measureable.
but in reality most apps spend 99% of their time waiting for events anyway, so for desktop apps the speedup gained from eliminating the X server is not measureable.
You are posting this in the wrong place, dude. Most people around here have never seen, much less have written, an event loop. This is a place to come and bitch about things you don’t understand.
the eariler poster seems happy abput directfb rendering opengl (not the pother way round)… why?
It’s the other way around – I was happy about having directfb atop opengl. Sadly this is not the case (if Luckett is right). There are many advantages in this approach:
1. Use the 3D hardware for all your drawing – not just for drawing in OpenGL windows. The contents of each window are rendered into a separate texture using OpenGL. Then you just slap these textures on the screen using textured quads. Add some blending and voila – transparent windows. Scale these quads and you get some neat animated effects – like seeing the window as it shrinks after minimizing it.
2. Avaibale drivers for any DRI-enabled 3D card (I think all except the NVidia ones). This will make the current DirectFB 2D drivers obsolete.
“If we have the graphics card hardware to do it anyway, why not? ”
Rasterman would proably agree with you.
You can do all those things using the 2D acceleration primitives, there’s no need to go through OpenGL to get those features.
1) Translucency: why should we use it?
Well, not to make all of your windows translucent and make everything harder to read of course!
Translucent stuff can actually _increase_ the visibility of some items on your screen.
Like menus with drop shadows, which makes the menu stand out (and it looks nice
.
2) Since a few months it’s possible to run DirectFB using a so called multi app core, which means you can run multiple apps instead of just one (like said in the previous comments).
“Like menus with drop shadows, which makes the menu stand out (and it looks nice
.”
Yeah, now try to read the label on the menu item. That’s sooo awful. I don’t want to see all the text I wrote in my text editor when I click on a menu.
Drop shadow yes. Translucent menus no!
You can do all those things using the 2D acceleration primitives, there’s no need to go through OpenGL to get those features.
Most of the silicon in the current graphics chips is dedicated to the 3D core and AFAIK when not using OpenGL this 3D core stays idle. Using the 3D core for anything more complex than copying pixels and drawing lines or quads should be faster. It gives you lots of features that can help you to optimize the drawing –
> Textures – stored in the on-board memory, that you can directly draw into, in case they don’t fit in the memory they can be accessed through the AGP bus. You can store in them the window contents, bitmaps and fonts
> Stencil/Z-Buffer, Alpha – now you can draw your alha-masked windows from front-to-back without drawing redundant pixels.
> FSAA – order-independent antialiasing, neat when drawing vector stuff.
> Advanced blending – fast window/menu shadows, fast transparency effects
Maybe the 2D core can do any of the above things just as fast – correct me if I am wrong.
Youch I can see it, running an accelerated desktop causing the gf fx 5800 to run constantly maxxed out due to using the T&L unit.
I wonder if you could hook up a vacuum cleaner tube up to the back of one of those things?
To add to the confusion, check out Fresco.org
Well, I guess I woudn’t be confused had I known more about graphics device programming and technologies.
BTW, can anyone suggest a reference (book, web site) for programming the device driver for different graphics cards?
How about getting graphics card programming manuals? Are these made public by thier respective companies? If not, which ones do make them public?
I wonder how the OpenBeOS people are writing their device drivers? I could not figure it out from browsing their web site.
Signed: EmptyHRT
I’ve said it before, I’ll say it again: the only thing worse than overlapped windows is transparent overlapped windows.
BTW, can anyone suggest a reference (book, web site) for programming the device driver for different graphics cards?
Well i haven’t done that in a really long time (way back in the days when i was doing assembly in msdos), i remember the vesa vbe standart documentation was a must, i don’t really know if their still around anymore, the vesa site is htpp://www.vesa.org.
I downloaded the overview pdf (2.25 MB, 10 pages). It doesn’t offer much introductory information, nor does the faq at directfb.org. The pdf was last updated Sept. 11, 2001.
My impressions are:
A. DirectFB is meant to be a direct replacement for XFree86.
B. The “linux framebuffer device” and “framebuffer driver” are things that come with the linux kernel (rather than with DirectFB). The framebuffer device(s) lives at /dev/fb*. The “framebuffer driver” runs in kernel space that talks directly to the “framebuffer device” I think.
C. A video card has a region of memory on it referred to as the “framebuffer”. The “framebuffer device” is a software abstraction of the actual framebuffer.
I guess that current video card drivers are XFree86 modules (or somesuch) and do not deal with the framebuffer device. No wait, one of the docs states that X makes use of the framebuffer device. Can anyone comment as to what the framebuffer device and the framebuffer driver are used for in a standard linux/X setup?
Also, I think there’s some connection between the console you see before X starts up and the framebuffer driver. I’ve heard the term “framebuffer console” bounce around — can anyone comment as to what that is exactly? Hmm… maybe each /dev/fb[0-7] corresponds to each virtual console… Ah! I bet the framebuffer device is how the linux kernel draws to the screen sans X.
For further reading, I found the framebuffer-HOWTO
http://en.tldp.org/HOWTO/Framebuffer-HOWTO.html
and tons more info and links here
http://www.linux-fbdev.org/
Oooh, and here’s a juicy one:
http://gtf.org/garzik/video/framebuffer.html
>> Yeah, now try to read the label on the menu item. That’s sooo awful. I don’t want to see all the text I wrote in my text editor when I click on a menu.
>> Drop shadow yes. Translucent menus no!
I said: menu + drop shadow.
I did not say: translucent menu + drop shadow.
😉
well rather than having translucency why not have an option to enable it for that window… viola, all fixed for everyone!
Avaibale drivers for any DRI-enabled 3D card (I think all except the NVidia ones). This will make the current DirectFB 2D drivers obsolete.
This is not the case. DRI merely provides a mechanism for shared access, it does not provide mechanisms for all the functionality of the DirectFB 2D drivers (e.g. initializing the hardware, setting the resolution)
The main reason X-Windows has become the standard across all Unix (and some non-Unix) OSes is because of its ultra-free MIT License. Using the LGPL for DirectFB (and Fresco too) virtually guarantees it will never be used as standard by any other OS than Linux. It will have to be extremely superior to X before the proprietary Unixes and BSDs will even look at it. It looks like it’s got a long way to go yet.
Really, what’s the point? Free software remains free software regardless of whether commercial forks are made. X is still completely free after all these years and it’s going to remain so. It bugs me that free software projects will shoot themselves in the foot like this for no discernible reason.
this is possible.
let them kiss.
btw, money is potential difference.
AFAIK, this dispute is FAR from resolved, especially if we supplant ‘MIT’ for ‘BSD’ (which fulfill the same role when contrasting GPL).
The jist of the issue goes like this:
BSD/MIT Licence
Good: More people are willing to touch the code because they can swipe it if they want.
Bad: Less modifications are fed back into the code base because some people just swipe the code.
GPL Licence
Good: All modified code is fed back into the code base.
Bad: Less people are willing to touch the code because they can’t swipe it.
So it boils down to whether it’s more important (from a software advancement perspective) to have the maximum number of hands in the code, or to make sure that EVERY hand shares. Since both BSD/MIT and GPL code are thriving in the OSS world, neither one seems that much better than the other.
rather than XF86 be good for Linux becasue then you can run any windowing system you like on top of DirectFB?
I pretty much agree with your analysis. GPL and MIT/BSD licenses have their places. I just think in this case the MIT/BSD would have been preferable. My personal bias is, as a *BSD user, I would be interested to see an alternative to X have a serious chance of becoming standard in those systems, and that ain’t going to happen.
BSD license discourages people IMO, because there’s no security about having your contributions remain free. I probably wouldn’t be contributing to Wine (as much) if it were still X11 licensed.