On Mon, Feb 25, 2008 at 2:41 AM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > I'll have to work with an Intel consumer electronics soon (CE2110, > [1]) so I started to investigate its capabilities and found that it > provides video overlays optimized for media playbacks, so you can > provide nice OSD (on screen display) without wasting much CPU, also > this board have some hardware decoders for h264 and mpeg2 and I guess > these do output to these overlays.
That's a nice board :) > They provide video drivers with their own library called GDL - > Graphics Device Library [2], with backend/engines for SDL and > DirectFB. This GDL seems to be pretty decent in hardware support, with > 2D including primitives like line, rectangle and blits (alpha, scaled > too [3]). This library itself is a tiny convenience library to issue > ioctl() to their kernel driver. > Now to Evas part: we have an outdated DirectFB which AFAIK nobody is > using or willing to maintain and we (more specifically Cedric) have > SDL almost integrated. > I know SDL is really bare bones, so overhead of it should be > minimum, however due it being bare bones I fear it not exposing > primitives we could benefit. I couldn't find any source code or patch > for SDL, so I'm not sure what they optimized. In SDL the only usable primitive is a SDL_FillRect when color as not alpha, nothing else. Mostly because they don't update alpha correctly in their blit function. > I don't know DirectFB more than reading their website some years > ago, but looking at their code and the patch provided by Intel, looks > like they do optimize some things. They have a README.txt with: > """ > """ 3. Current supported GDL accelerated features of DirectFB > """ 1) Overlay surface source color key is supported.. > """ 2) Below drawing functions are accelerated via GDL for all > video system surfaces: > """ draw lines; > """ draw rectangles, fill rectangles, fill triangle with single color; > """ strecth blt with alpha blending and alpha scaler. DirectFB API provide a usefull api for blenging, stretching and filling. So definitivelly, if you want something accelerated, it's a good solution. Another interesting point is that this API is also provided by other hardware manufacturer for their set top box. Now some draw back, the implementation I saw from manufacturer where slow and based on outdated version of directfb. They didn't follow the directfb api completely for video as they wanted not to directly expose the decoded video to the underlying application (something related to media content protection). This could prevent us from doing nice effect like emotion give us the possibility. > So I'm not sure on how to proceed. Would it be better to get DirectFB > in shape, use SDL or write Evas GDL engine? Maybe my requirements can > help somehow: > - basic usage will be a digital tv set top box, so it's full high > definition video with eventually some nice OSD on top of it. > - it would be great to have semi-transparent OSD. > - CPU is ARM/Xscale at 1Ghz, so fancy on-cpu graphics may not be > possible (ie: emotion). > - future will require me to run more things than just my > application, maybe having Firefox and some other programs. This may be > a good point for DirectFB? (I don't know if they compiled with the > multi-app support, but given they provide a patch, it may be possible > to recompile with this support). I have mostly the same question right now, but not for the intel hardware. I would add that I am sure that my hardware provide a way to decode multiple video at a time, and merge them using the 2D graphic engine with support for alpha channel. Meaning I am sure that if I do every thing from scratch, I should be able to do the thing emotion give us the possibility to do. But currently by using SDL or DirectFB, it's not possible. With what I read from the intel spec, you have multiple video plan, so you can do what I am doing now. Just play video on the dedicated plan you have, setup the SDL backend with a 32bpp surface on another layer on top of the video layer and use SDL transparency for OSD effect. It will work well in software, I am doing this on my little MIPS at 250Mhz. But no fancy effect or anything on your video. The evas sdl backend work great in that case. > If you have any knowledge of this topic, please help. I'm still a bit > confused about this overlay thing, maybe it's very helpful, as if you > can have a ARGB overlay with my GUI so I port Evas to it, run it as > ARGB surface and play the video on the background from another place. > But maybe it's not like that and it's just a way to get hardware to > output to some region directly (like h264/mpeg2 decoders writing to > it) and I'd have to draw my surface on top of it using colorkey or > retrieving the pixels (possible slow) to do alpha blend, making things > more difficult. > What's the state of DirectFB? Was it running fine one day (ie: > directfb part is okay, it just lag behind Evas api changes)? If they really provide a full, up to date and fast implementation of DirectFB, I think it could be interesting as you should be able to accelerate every thing and have the same engine on PC and on your development board (really help full for debugging). The think you should look in their implementation of DirectFB, is how they give order to the underlying hardware (if it's with many ioctl per graphical operation, you can assume it will be really dead slow and software implementation will be faster). I don't know myself right now what kind of accelerated backend I will do. DirectFB, proprietary interface or something else. Just wanted to share what I already find. -- Cedric BAIL ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
