[LINUX] DirectFB and DirectFBGL hardware graphics acceleration API support in XBMC?

The two reasons I ask is if XBMC GUI and video rendering could be accelerated by DirectFB hardware abstation layer is firstly; it could in theory be faster to use DirectFB than the full X Window System, and secondly if XBMC supported DirectFB then XBMC could someday possibly be ported to run on some ARM-based embedded systems Linux devices similar to Neuros OSD2.0, the BeagleBoard (Beagle Board), the Pandora portable game-console, the NMT (Networked Media Tank), or the Roku Netflix Player which features hardware graphic acceleration via DirectFB, (using Broadcom, NXP, Sigma Designs, or Texas Instruments Media SoC processors which also features hardware decoding of H.264 and many other popular codecs).

Sure XBMC will probably never be ported to run on ARM architecture CPU by anyone of the current Team-XBMC developers as they probably do not have the hardware nor the personal interest in doing so, but there might be other industrious third-parties whom might be interested in using XBMC as their framework for a small and cheap stand-alone set-top-box type media players running on ARM based Multimedia System-on-Chip instead of a x86 processor.

So the questions are, could the DirectFB library be used to bypass XBMC's need to use X Window System?
http://elinux.org/DirectFB
http://en.wikipedia.org/wiki/DirectFB
http://www.directfb.org

Quote:DirectFB stands for Direct Frame Buffer. It is a software library for the GNU/Linux operating system that provides "hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers on top of the Linux Framebuffer Device

If not directly then maybe through XDirectFB?

Quote:XDirectFB is a rootless X Server implementation that uses DirectFB windows for X11 top-level windows. With XDirectFB, programmers do not have to rewrite their code to use the DirectFB API

Does SDL (Simple DirectMedia Layer) support DirectFB/XDirectFB?
http://www.libsdl.org/faq.php?action=lis...category=9
http://mail.directfb.org/pipermail/direc...01571.html

DirectFBGL is an OpenGL extension for DirectFB/XDirectFB that uses DRI in Mesa to support OpenGL hardware acceleration:
http://www.directfb.org/download/DirectFBGL/
http://dot.kde.org/1058619204/1058722202/


What are be the Pros and Cons of using DirectFB/XDirectFB/DirectFBGL over X11 or OpenGL if it would be possible?



PS! The Neuros OSD2.0 Development Kit is probably right now the be the best suited platforms for developing this initially as they are Linux embedded based and have free open documentation, and relatively speaking is not too expensive at $250(US) plus shipping for the Neuros OSD2.0 Development Kit.

hi,

i'm very interested in this too. i think if you use the framebuffer, you have less overhead.

you can compile sdl to use the framebuffer. i have done this for SDLMAME (arcade emulator).

benefids:
1. no X, so much quicker to boot xbmc
2. it can easaly be ported to other embedded platforms.

plz reply, if anyone is interested in this topic

cheers,
ray

there is no opengl for the framebuffer in general (some platforms do have openglES there however). so i bet in your case it is not even an option

hi,Gamester17,is there any refresh of this topic? can we make the SDL to use FB not the x11 as the backend,could we get rid of the X11?

I really never understood why xbmc needs opengl. The graphics aren't 3D so it means that any 2D accelerated framebuffer should do. So I agree that this way it would be possible to run xbmc even on platforms that have no opengl support.

blotunga Wrote:I really never understood why xbmc needs opengl. The graphics aren't 3D so it means that any 2D accelerated framebuffer should do. So I agree that this way it would be possible to run xbmc even on platforms that have no opengl support.

YV12 to RGB color space conversion. That's expensive in CPU but dirt cheap with GPU with OpenGL and shaders.

blotunga Wrote:I really never understood why xbmc needs opengl. The graphics aren't 3D so it means that any 2D accelerated framebuffer should do. So I agree that this way it would be possible to run xbmc even on platforms that have no opengl support.

Many skins uses perspective rendering, i.e. 3D.

And what davilla said. In the embedded market some have hardware to do the conversion (in example beagleboard) which we use there since their GPU's aren't strong enough.

More info:
https://github.com/xbmc/xbmc/pull/454