On https://github.com/turran/efl-egueb you’ll find the Egüeb’s EFL integration project.
Basically this projects does all the links between the different EFL technologies: Ecore, Evas, Edje and Egüeb.

Given that Egüeb is based on the “features” concept to support different features on the documents (drawing, animations, input events, etc) all of theme can be easily matched against EFL’s abstraction. For example all the input events are handled automatically using the Ecore Event abstraction. For animated documents (documents that use the SMIL elements) an Ecore Timer is used. For drawing an Ecore Idler is used, etc.

So after a hard time developing Egueb and mainly the SVG library. I wanted to try again Eon for changing some perspective and see if Enesim’s API was still enough for such library.

After taking a look on the old code and see how hard it depended on Ender (the old object description library) I decided to make it use Egueb itself as it’s core object system. It was natural given that Egueb’s Dom implementation has improved so much that at the end it fits perfect on what Ender was trying to do.

So first I took Ender’s dependency, coded some initial widgets using DOM’s way of doing it, ported Escen to use SMIL elements (The ‘set’ and ‘animate’ elements) and put all the pieces  together to be as close as what it was before but using another libraries behind.

The result is that I can declare the application’s widget using XML (that means that I can also do CSS on the widgets for fine tuning some specific attributes) load it and interact with it.

This is the file contents I used for the following video

<eon>  
  <stack orientation="vertical">  
    <button id="button01">  
      <label>My very own label</label>  
    </button>  
    <button id="button02">  
      <label>My second button</label>  
    </button>  
    <button id="button03">  
      <label>My third button</label>  
    </button>  
    <button id="button04">  
      <label>Button 4th</label>  
    </button>  
  </stack>  
</eon>  

It has been a year and a half from the last post, but none of the developments have stopped during this time. I’ll try to do several posts in the following days explaining the different improvements on the whole stack of libraries.

In Enesim, I’ve been porting all the renderer algorithms to the OpenGL backend and thus, all the libraries that depend on Enesim for drawing can use OpenGL out of the box without any specific modification but passing an Enesim_Surface created by the OpenGL’s Enesim_Pool.

Another improvement is that finally the NVIDIA’s path extension can be used (when available) for the path renderer, besides Enesim own software and OpenGL implementations.

On the current stack of libraries that I’m developing, having OpenGL support means that having SVG graphics/scenes using OpenGL for drawing is possible. In the same way, drawing Eon’s widgets can be done using OpenGL without any special effort.

In order to advance on the automatic bindings for Ender elements, Escen is broken and thus Eon. Sadly Escen needs a heavy refactor right now, but at least new features have reached Ender. Now, it is possible to define functions for structs so basically we can now map into Ender more C libraries. This was a requirement for Ender long time ago to basically support properties and functions for known-size native objects. This allows for example to match the following header:

typedef struct _Enesim_Matrix  
{  
 double xx, xy, xz;  
 double yx, yy, yz;  
 double zx, zy, zz;  
} Enesim_Matrix;  
  
EAPI void enesim_matrix_translate(Enesim_Matrix *t, double tx, double ty);  
EAPI void enesim_matrix_scale(Enesim_Matrix *t, double sx, double sy);  
EAPI void enesim_matrix_rotate(Enesim_Matrix *t, double rad);

With the following Ender definition:

It’s been a long time since I write here, but the changes on the enesim stack deserve a new post. In the past months a lot of new features have been added and lots of bugs have been fixed. Just a small update of the changes given that I’m about to leave for vacations …

Enesim is now more OpenGL friendly, it is possible to render complete SVG files with GL, still not as good as the software based backend, but is evolving nicely.

Egueb and specially Esvg is now able to render animated SVG files, it is still missing input (to be able to interact with the SVG files) and scripting (Javascript) support. But those will come in a near future. As an example, I’m attaching an animated clock rendered (and animated) with Esvg. You’ll see some differences between the original file and our own version, mostly the lack of filters and some text glitches.

Finally I got some time to start implementing the OpenGL backend interface on the renderer side. On the surface side, it was already possible to create surfaces with a GL texture associated using the OpenGL Enesim’s pool but we were missing renderers.

Right now only simple renderers are implemented through fragment shaders. Mainly: stripes, checker and background. The approach is to always use shaders, being it geometric, fragment or vertex, I’m working on implementing geometric shaders for the different shapes but I don’t have the hardware that supports it, so I suppose it will have to wait …. but good things will come in the future, like having a full GUI (Eon) done on OpenGL or rendering SVG files (ESVG) with full hardware acceleration

Anyway, here is a screenshot, everyone loves screenshots! Here is a simple GLX window displaying a surface which was previously rendered with a stripes renderer which is  rotated.

Sometime ago I started creating a library for SVG parsing and rendering. It was called Esvg. The initial version didn’t do much, it was just using cairo to actually draw the different SVG tags. Now, a new version of Esvg has arrived into Enesim’s repository, thanks to Vincent and his great effort to make this library a success.

The main ideas we had in mind for this library were:

About 6 years ago I wrote a post about Evoak, reading it I noticed how bad my posting abilities are (not that Im good now either) because there was no exaplanation on what my goal was, it was a post of about the status of something and I suppose is difficult to valorate a milestone whenever you dont know the final goal. On that time I was really fascinated about the evoak concept but was scared of the amount of work it was needed given the Evas unstability and Edje emerge. How to code such a great idea when you know your work will be uselss two months later?

I used Evoak on my final project on the univserity, it was a real success and for me it was enviosining a different approach to the classic server-client we had on that time (and still now), X11. This topic might be taken care off on another post.

Six years later and a complete different set of libraries and tools I’m able to code again that idea. The responsible of such possibility is Ender. When I started creating Enesim, Emage and several other libraries my main goal was to actually replace some of the bits of the current EFL stack specially Evas, to be able to improve and advance with new and good technical ideas. From the current state of EFL I would say that both projects are riding its own road for now, who knows later … The situation was that I was trying to create some kind of object system or better, a description system which will allow me to serialize properties and values easily, if I were able to create a toolkit/canvas library using only properties and values then the next step, that is, send those properties through the network, would be easy and the Evoak concept could rise again.

That moment has arrived. Everything is still on an alpha status (everything is just a proof of concept) but the idea is working. Right now, with Eon being a toolkit system with objects I can create and manipulate on a generic way (through properties, values and events) I was able to create such network bridge to serialize the widgets data through the network and create a server which shows those applications without any change. If you take a look on the ecore_remote backend of Eon and the eon_server application on the Enesim repository you’ll see the actual implementation. This is a very good milestone on the idea I wanted to accomplish: bring Evoak back! :)

Now that you know how to create renderers and draw them into a surface as seen on the previous post, now we will see how to achieve the image below only using Enesim renderers, no images are allowed! Thanks Jose for the example code.

I’ll update this post as soon as I have time …

The complete code can be found here

This is the first post in a series of tutorial posts for every component on the Enesim project. From Enesim itself to Eon. On this first tutorial we’ll learn how to draw this sample image:

The first step is to create the renderer we want to draw. A renderer is just an abstraction of something that draws, nothing else. It can be a rectangle, a circle a gradient or even a bubble, as long as it draws something we are fine. This is the main difference between Enesim and other graphics libraries, on Enesim there’s no concept of graphics primitives or texturizing, every renderer is both a primitive and a texture.

Let’s begin by creating our rectangle renderer

Enesim_Renderer *r;  
r = enesim_renderer_rectangle_new();  

The Enesim__Renderer design in a way has an object oriented approach. Every renderer inherits from the base Enesim_Renderer type and so, you can use the generic renderer API to set generic renderer properties. Also note that a rectangle renderer also inherits from a shape and again you can use all the shape API. More on this later.

Now let’s set some common properties

This was something I had in mind for a long time, not neccessary OpenCL but an usable way to make a “backend” system for renderers and surfaces/buffers. That moment has arrived. Right now the enesim code has a well defined backend system and an incipient OpenCL support. Given the nature of a renderer each one should provide each own OpenCL algorithm but at least Enesim provides a good abstraction to define such algorithms and interact with them.

The pool subsytem has been refactored in a way that a pool should create surfaces or buffers and define its backend type. Given that, once a renderer element wants to draw into a surface, we can call the correct functions based on the backend and the associated data of a surface.

Still there are things to do on Enesim and specifically on other subsystems of the library (like being able to make converters use also the backend system, like having a YUV422 -> ARGB converter on OpenCL or stuff like that), but is a very good step on the road of the 1.0 release. The only implementation of an OpenCL renderer is done on the “background” renderer given its simpleness, but is a good start to understand how OpenCL works and what common arguments are needed for every renderer.

Later, with this approach, we can easily add an OpenGL shader approach for renderers and a texture based software pool :)

The enesim stack has been actively developed on the past months, we have lots of new features and new design concepts but this post is about threaded rendering. Recently a threaded rendering path has been committed into enesim given outstanding results, for examlple running the benchmark application with the circle.escen example we have:

Without threaded rendering

The Equanime project right now is idle but not dead. I still want to finish that project but given the limited time I have I need to prioritize on what project I put all my effort and resources. That’s why the Enesim framework is getting all my attention this days, once the toolkit library is done, it will be a good moment to retake the Equanime development given that then we can start drawing things on the target devices of Equanime. Even so I’ve created a group for discussing the development of the project.

Now with metadatafs you can easily update the id3 information on your music files by simply moving around directories. Still need to get rid of orphans fields on the database but that will come soon.

It’s been a while since my last post. But now it is time to announce something new I’m doing on my spare time (which is almost none this weeks/months). Basically it is a FUSE filesystem that generates a directory tree based on the mp3 (or ogg, flac, whatever) metadata fields.

Basically once you have mounted your mp3 directory, you’ll get something like this:
/Album
/Artist
/Files
/Title
/Genre

It allows you to browse your music collection with the common file operations (open(), readdir(), etc). For now it only has read access, i.e you can only browse, list and search, but there’s a TODO item to allow write operations, that is, a way to write the metadata information based on the file operations you do on the files, like renaming the Album’s name.

You can find more information in the google code project

The past weeks I’ve coding again the Neuros OSD2 development board on my spare times, given the months that have passed since last time I touched that device I thought that the Linux community would have brought a better media framework. Sadly it hasn’t changed much as many people think.

Every non-media subsystem on Linux seems to work good and well stable but when you need to bring latest video and graphics technologies to user level you really have a problem. (I don’t really want to think how it would be if your salary depends on such thing, well in fact I do know …)

Basically, on Linux you have the following subsystems:

It has some time since my last post. During this months I’ve been fixing, adding features and fixing (yes, again) several libraries on the stack I’ve been developing. Lots of stuff have changed, Enesim’s API is getting more stable, Eon and Ekeko have hit E’s subversion, etc.

Loading xml files for different scenes is great, but not too great if you want to test the usability of the system, so I’ve started an Eon builder. A way to create objects, define and assign paint objects, animate them, etc, etc. Here’s a simple demo of what’s going on there

As you see, it is on a very basic stage, you can move objects, resize them, etc. There’s no toolkit used (yet?) mainly because I haven’t decided yet what’s the best approach, something similar to edje? an external xml + put-your-preferred-scripting-language? something similar to CSS but more powerful? Need to solve this before starting with the toolkit …

The past few months I’ve been away from main EFL development. With no particular reason than to build a different approach to the canvas library and to bring up this new concepts / features into mainline, similar to what happened with Eina.

The stack I’ve been developing is as follows:

This days I wanted to profile the paroli application, there are some issues with the scrolling and loading time. So I first took the loading time issue and tried to solve it. Right now Enlightenment takes around 7 seconds to fully load and Paroli takes around 20 seconds. As E17 loads Paroli as a startup application before loading the modules, the time GTA02 takes to show up Paroli since the moment the X server has started is around 30 seconds.

The current E17 config we have is a default one, we basically load every module for E17 even if it is not used for Paroli. After tweaking the configuration and making illume’s module to be loaded in an async way, the loading of E17 now takes half of the time, only 3.5 seconds (The new config is already committed). Sadly Paroli itself still takes too much time.

Note that all the numbers above are on a NFS system, but the relative slowness is the same for a flash filesystem.

Yesterday I’ve been testing the xrender engine on evas using the current EXA acceleration found in glamo (that is: solid fills and surface blitting). Sadly the test was taking ages to finish and even after walking up and leaving it the whole night it didnt finish but hang on the text test.

After my tremendous problems building my build environment I have finally succeed :)
So I had the chance to give xorg-video-glamo a try and see how well it behaves. To do the benchmark I used expedite and the results are:

2.76 , Image Blend Unscaled  
12.69 , Image Blend Solid Unscaled  
1.56 , Image Blend Nearest Scaled  
8.77 , Image Blend Nearest Solid Scaled  
0.45 , Image Blend Smooth Scaled  
5.93 , Image Blend Smooth Solid Scaled  
5.02 , Image Blend Nearest Same Scaled  
22.05 , Image Blend Nearest Solid Same Scaled  
1.27 , Image Blend Smooth Same Scaled  
11.84 , Image Blend Smooth Solid Same Scaled  
0.51 , Image Blend Border  
6.67 , Image Blend Solid Border  
0.44 , Image Blend Border Recolor  
4.29 , Image Quality Scale  
7.22 , Image Data ARGB  
4.89 , Image Data ARGB Alpha  
6.54 , Image Data YCbCr 601 Pointer List  
6.04 , Image Data YCbCr 601 Pointer List Wide Stride  
6.67 , Image Crossfade  
9.28 , Text Basic  
1.05 , Text Styles  
0.79 , Text Styles Different Strings  
5.64 , Text Change  
5.67 , Textblock Basic  
4.67 , Textblock Intl  
1.81 , Rect Blend  
9.57 , Rect Solid  
69.84 , Rect Blend Few  
84.22 , Rect Solid Few  
41.09 , Image Blend Occlude 1 Few  
24.00 , Image Blend Occlude 2 Few  
17.50 , Image Blend Occlude 3 Few  
43.26 , Image Blend Occlude 1  
14.59 , Image Blend Occlude 2  
4.87 , Image Blend Occlude 3  
27.31 , Image Blend Occlude 1 Many  
6.81 , Image Blend Occlude 2 Many  
2.21 , Image Blend Occlude 3 Many  
3.79 , Image Blend Occlude 1 Very Many  
0.66 , Image Blend Occlude 2 Very Many  
0.36 , Image Blend Occlude 3 Very Many  
3.51 , Polygon Blend  
11.86 , EVAS SPEED  

The past month i’ve been trying to setup my build environment to what I am used to have. After working for some years on embedded devices, my usual environment has always have a rootfs on my local box where I copy my developments and then the target device just mounts it’s rootfs via NFS. This setup is widely used as it reduces the risk of converting your device into a brick. No need for burning the image or installing packages via some kind of specific intaller, no need for NAND/NOR writing.

Openmoko uses Openembedded and from its name i thought that it will let me have this setup fairly easy. The truth is that my experience with it was null, but looking on the documentation it remind me a lot to what Gentoo/Portage is.

Sadly, my impressions so far are very dissapointing. My goal was something very easy, just give me a rootfs and i’ll manage the development, i didnt want to learn another pacakge system, just have a base system and deploy somehow development into it.

My first problem with OE was how to create a base system. So first i followed the OE tutorial, and after setting up my local.conf I bitbaked nano. On the beginning it gave me some errors with qemu, basically some include errors:

qemu-native-0.9.1-r7/qemu-0.9.1/linux-user/syscall.c:79:26: warning: linux/dirent.h: No such file or directory

A simple patch fixed it

--- linux-user/syscall.c 2009-02-04 22:27:40.000000000 +0100  
+++ linux-user/syscall.new 2009-02-04 22:37:42.000000000 +0100  
@@ -76,7 +76,7 @@  
#include  
#include  
#include  
-#include  
+#include  
#include  
  
#include "qemu.h"  

I put it on

packages/qemu/qemu-0.9.1

and the compilation continued. Then I bitbake xorg-xserver, around 5K package, no problem i’ll wait. My first problem arised: Ok, now i have some packages, what now? I still want my rootfs! So I guessed I needed an image, there were around 80 image names, how to know what are those for? what do they will bitbake? On portage i would just do an

emerge -p <image>

and it will give me the list of packages the portage system will install and wont list me the already installed, or

emerge -s <image>

will give me the description. For me those image names were just cryptic names with no meaning at all. So i give bitbake a chance and run

bitbake openmoko-base-image

Now i have to compile and install 5000 packages more. No way thanks.

I thought OE will be an incremental pacakge system, where i have a simple base system, with all the needed directories, device nodes created and just add packages to it. But looks like it isnt. The problem was even worst when i realized that in order to install a pacakge i will need to run a command in the target device … WTF? im a developer not a user.

Now I know there are ways to create a rootfs on the local box like Werner’s solution.

So yesterday i gave OpenWRT a chance, following this steps. I have to say that it was fairly easy, just two commands and is done. One thing i really appreciated was that the menuconfig allowed me select what output form i want my rootfs to be: jffs2, ext2, and tgz, beside others. Now i have my rootfs and im ready to mount it from my phone via NFS.

Look that im new with OE, for sure that some experts out there handle it correctly and might have a great solution for my case, from a newcomer point of view i was amazed that simple things like search a package, create a rootfs in tgz or list the dependant packages were not easy enough. I just want to develop :)

After more than a month, my Freerunner has arrived! There were some issues with DHL, looks like my phone number was not set correctly and they were calling another person. So it went back to Taiwan and sent again to Barcelona. I can’t wait to test it, try Evas there, develop for it, etc …. The past weeks i have only read, research and read again with no device to test or develop to, finally i can start coding :) Great times will come!

Etch, a timeline based animation library, finally arrives to E’s svn repository. Basically you define animations based on key frames and a data type (integer, float, argb colors, etc), set the interpolation between those key frames and your callbacks will be called at every frame based on the number of frames per second that you have set.

Etch *e;  
e = etch_new();  
etch_timer_fps_set(e, 30);  
a = etch_animation_add(e, ETCH_UINT32, _animation_cb, NULL);  
k = etch_animation_keyframe_add(a);  
etch_animation_keyframe_type_set(k, ETCH_ANIMATION_COSIN);  
etch_animation_keyframe_value_set(k, 10);  
etch_animation_keyframe_time_set(k, 3, 3015);  

Note that this library is totally agnostic about the main loop handler, you just need to call etch_timer_tick(e) to update the internal system.

The example below is an application that transforms an evas’ image and moves it based on a couple of Etch’s animations and Enesim’s transformation functions.

After having issues with my previous blog, (thanks Hisham anyway!) I decided to move all of my posts to blogger, sadly all the posts’ attachments (pictures, videos, packages, etc) are lost. It might take some time before finding any of those old files …

Hi all, as some of you already know, I was hacking the Neuros OSD device some time ago, doing a kernel porting project using standard Linux API for some functional blocks, such as V4L, FB, etc. After some negotiations I officially work for Neuros Technologies now, focusing mainly on low level stuff and multimedia for the next generation Neuros OSD2 =)

On Linux version 2.6.23 (or .22, can’t recall right now) the UIO (User space Input Output) API was included. It brought up several discussions, quoting Andrew Morton:

It all began when discussing some ideas about Evas, about splitting the Evas’ common engine as a new direct rendering library for easy testing, to merge both a8r8g8b8 and r5g6b5 formats into a common place and for cases where one needs to draw without the canvas approach. So I took the code and did a new library called Emage (which is under the svn of efl-research Google’s code) but then i realized that it was still too restrictive, mainly because the use of the graphic context, so i started a new library called Enesim. Enesim is a library that implements several graphics algorithms/concepts but flexible enough to draw whatever you want with your own pipeline. You have renderers, surfaces, rasterizers, scanlines, etc. The main purpose of this library was to be able to code vector graphics and raster graphics having a common graphics code base.

Nowadays there are lots of devices that include Linux and other free libraries or applications on it. With the GPL license you are supposed to liberate the source code in case you have modified it, which is really great but suffers in a key point, merging.

Finally I’ve changed the server where my previous (and nonfunctional) web page was (thanks Hisham!). The only problem is that I couldn’t import my previous posts, the Typo version was exactly the same but for some reason it didn’t work out and honestly I don’t have time to learn, hack or fix Typo for this.

After talking to the guys behind Google’s code they have increased the project size and now I can code fine there. The kernel boots correctly but there are too may things to code, but hopefully this is a start. There hasn’t been too much enthusiasm on the GP2X community as i thought at the beginning with this project, in any case this helped me to get started on the ARM architecture and learn how to port a a new SoC into the Linux Kernel

After changing Ecore_Fb to handle Linux Input Device as the main input driver available I decided to go further and implement several ideas I have in mind:

At work I’ve been told to do a project based on the Neuros OSD. Suddenly I became very interested on this project and (as in the case of the GP2X) was interested on kernel stuff and the EFL. I started a project to port the Neuros’ closed source drivers into open ones. I’ve coded several drivers already like the framebuffer (one of the most important beside the DSP), I2C, serial, etc. Check the project page if you are interested on this.

A few weeks ago i bought a gp2x portable console, I was interested on this device because it has Linux as operating system and also because there’s a large community behind it. I have several plans with it and Enlightenmnent (mainly the EFL); but before that, the first step i should do is to port the linux 2.6.x to it. I’ve just registered a new Google Code’s project but I’m having issues with it, don’t know if it’s better to register with SourceForge. There will be several news soon ….

I have uploaded the changes I’ve done to Evas and Evoak. The Evas package is renamed to evas_core for easy interoperation between the current evas and my own. My changes are:

I started coding a framebuffer driver for a very old video card i have, a SiS 6326 AGP. Ive been wanting to code this for a while (because i have the datasheet) but never had a clear understanding of how a video card actually works. Finally after some weekends i have a linux framebuffer device working.

I have to code an accelerated driver for the AMD/National Gx1 graphics device for my final project at the university. I really dislike this hardware architecture, SoftVGA?. Also the board itself is a crap, it is a SBC with a buggy BIOS. Here are a few screenshot that show the problems with the geode fb driver, i talked to the fbdev people but seems there’s no easy solution.