Look Ma, no Evas!

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:

• Enesim: The graphics library. You can find more information about it at the wiki page
  
• Emage: Is a library to load and save images in different formats. It supports synchronous and asynchronous operation and also user provided modules.
  
• Etch: The animation library. It basically interpolates two values using several algorithms, like: discrete, linear, sin, with bezier control points, etc.
  
• Ekeko: An OO property system. It has an abstract canvas and renderable types, UI events, generic properties, syncrhonous and asynchronous dispatching, among other features.
  
• Eon: This is where all the efforts join. Eon started as an improvment to Etk (still called etk2 on the repository), but then the initial idea diverge and now the code base is very different to what Etk is. Basically Eon has support for basic renderable shapes, like images or rectangles, support for subcanvases, transformations for images, etc.
  

Here you can see a simple demo with some features I've done the past days: animated matrix transformations




Update: To create the video I used this xml. Eon has a parser for XML based scene files.


<etk w="100%" h="100%" id="canvas01">
<rect x="0" y="0" w="100%" h="100%" color="white" id="rect01"/>
<image x="40%" y="25%" w="50%" h="50%" file="tiger.png" id="image01">
<animMatrix name="matrix" type="0" dur="3s" from="0" to="0.7" calc="0" begin="click" repeat="-1" id="anim01"/>
<anim name="color" dur="5s" from="0xffff0000" to="0x66660000" calc="0" begin="click" repeat="-1" id="anim02"/>
</image>
<rect x="60%" y="10%" w="25%" h="25%" color="0xaa0000aa" id="rect02">
<anim name="y" dur="10s" from="10%" to="80%" calc="0" begin="click" repeat="3"/>
<anim name="color" dur="5s" from="blue" to="0xaaaaaaaa" calc="0" begin="click" repeat="-1"/>
</rect>
<rect x="10%" y="45%" w="25%" h="25%" color="red" id="rect02">
<anim id="myanim" name="x" dur="3s" from="10%" to="60%" calc="0" begin="click" repeat="1"/>
<anim id="anim04" name="color" dur="5s" from="red" to="0xaaaaaaaa" calc="0" begin="#myanim.stop" repeat="-1"/>
</rect>
</etk>


Paroli load time

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.

Glamo Xrender Benchmark with Expedite

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.

So, i wanted to test just the glue found on XRender and the implementation of it using EXA, but without painting anything, just memory moves from system memory to VRAM and the neccesary logic found on the Evas' Xrender engine. So I "removed" (just return TRUE) the functions from the xf86-video-glamo driver and .... here are the results:

Benchmark	Software X11	XRender without painting
Image Blend Unscaled	2.76	????
Image Blend Solid Unscaled	12.69	13.72
Image Blend Nearest Scaled	1.56	18.14
Image Blend Nearest Solid Scaled	8.77	18.00
Image Blend Smooth Scaled	0.45	18.22
Image Blend Smooth Solid Scaled	5.93	17.59
Image Blend Nearest Same Scaled	5.02	21.26
Image Blend Nearest Solid Same Scaled	22.05	17.73
Image Blend Smooth Same Scaled	1.27	20.96
Image Blend Smooth Solid Same Scaled	11.84	17.76
Image Blend Border	0.51	1.83
Image Blend Solid Border	6.67	1.97
Image Blend Border Recolor	0.44	1.23
Image Quality Scale	4.29	1.97
Image Data ARGB	7.22	3.71
Image Data ARGB Alpha	4.89	1.70
Image Data YCbCr 601 Pointer List	6.54	3.16
Image Data YCbCr 601 Pointer List Wide Stride	6.04	5.40
Image Crossfade	6.67	4.61
Text Basic	9.28	2.25
Text Styles	1.05	0.17
Text Styles Different Strings	0.79	0.14
Text Change	5.64	1.86
Textblock Basic	5.67	1.50
Textblock Intl	4.67	2.46
Rect Blend	1.81	9.66
Rect Solid	9.57	18.02
Rect Blend Few	69.84	?????
Rect Solid Few	84.22	61.79
Image Blend Occlude 1 Few	41.09	196.75
Image Blend Occlude 2 Few	24.00	47.37
Image Blend Occlude 3 Few	17.50	70.32
Image Blend Occlude 1	43.26	26.20
Image Blend Occlude 2	14.59	14.03
Image Blend Occlude 3	4.87	21.06
Image Blend Occlude 1 Many	27.31	12.14
Image Blend Occlude 2 Many	6.81	4.61
Image Blend Occlude 3 Many	2.21	????
Image Blend Occlude 1 Very Many	3.79	1.54
Image Blend Occlude 2 Very Many	0.66	0.43
Image Blend Occlude 3 Very Many	0.36	0.58
Polygon Blend	3.51	1.69
EVAS SPEED	11.86	18.66

The results are very disappointing, there are several places where drawing on software is better than just doing the logic on XRender/EXA to achieve the same result but without drawing. And in the tests where XRender/EXA is better the speed up doesn't worth as the drawing will be for sure slower. Note that the Glamo chip can only do raster operations into a destination surface of format RGB565, which means that there wont be any acceleration even if the blending is possible on hardware as Evas uses ARGB8888 premul.

Then, how to improve the speed of the rendering on Evas specifically for this chip? The path through XRender/EXA is worthless, is there any other way? Well. one possibility we could use, is to use the Evas' software_16 engine (a destination surface of format RGB565) to reduce the bandwidth needed, but how to match that with the XRender API?

Another solution could be to leave the efforts on xf86-video-glamo acceleration and just build a specific Evas engine for glamo. Mmap the whole framebuffer memory and manage it through Eina's memory pool manager, handle the surfaces ourselves and do a mix between software_16 and this specific engine. A lot of work, yes, but looks like the only solution (X away) that can give us some results. But there's a problem, how to send the changes into the displayed X window? because in our engine we'll use a VRAM backbuffer and we can't know from a X client the phyisical memory of the area the window is being drawn. So we'll have a roundtrip here, physical memory (our glamo surface) -> virtual memory (Xshm/X memory) -> physical memory (destination framebuffer), that for sure will remove any speedup.

Suggestions?

Initial Benchmark of the xf86-video-glamo on GTA02

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 benchmark took around half an hour to end and from the final EVAS SPEED value, it is really, really slow.

Note that right now the driver is just a wrapper on top of the fbdev, so no acceleration is coded yet, only software based rendering and giving that the CPU isn't that fast either, there's no surprise on the benchmark.

The Xrender acceleration is one of the possibilities to improve the performance and the good news is that Evas already provides a Xrender based engine. So let's get the hands dirty and start hacking the driver! :)

Openembedded, OpenWrt, Gentoo Portage

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 :)

Finally the phone arrived!

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 hits E's svn

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.