On Wed, Feb 27, 2008 at 11:32 AM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Wed, 27 Feb 2008, Nicolas Aguirre wrote: > > > On 2/27/08, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > > > I think that we should add evas filters. It should be very interresting for > > student (study of the internal behaviour of evas, interresting algorithm to > > perfmorm different filters...). > > Rotation, perspective, reflection can be a good beginning and maybe add > > gradient clips, blur .... > > actually, there is already a mention about evas filters in the wiki. But > maybe we should be a bit more precise on which filters we would like > > That makes me think that we must add turran's work
Hi all, I think SoC is a good opportunity for all of us, as I've been named several times about what i have been coding this months here is a brief explanaition of it (in order of importance): Enesim: This library started as a direct rendering gfx library, but a very generic one, with no context; this decision was made to allow different libraries built on top of enesim to define their own context api. It works very nice, but i'd like to implement more pixel formats and more porter/duff operations. Also there's support for simple transformations (based on a 3x3 matrix) but filters will be a good thing to have here too. Eina: A common library for data types, several times on the ml we have discussed the problems with the efl about not having a common implementation of lists/hashes/whatever. This is an attempt. TODO: add evas data types too and merge into a common API/implementation, for now there's only the ecore data types and a new lazy allocator. Ekeko: The idea here is to build a common canvas framework, very simple, supporting abstract objects and general input devices, it is similar to what evas has inside, but the idea is to be able to build evas itself on top of this, a 2d game, a svg canvas, a window manager, or whatever you would want. The concepts of filters and subcavnas are already provided on the example directory. TODO: generic input system. Equanime: This library isnt coded yet, but if someone is interested i'll explain what i'll do. To make it short, it's a simplified version of DirectFB, not aiming only linux as the backend (the framebuffer). It will match the common hw found on simple/embedded graphics devices, like layers, outputs, regions and that's it (maybe 2d engine); no surface allocator, no window manager, no concept of input devices, etc. (the below projects have too many todo's to list them) Evg: Is an attempt to build an implementation of the openvg standard on top of enesim, mayeb supporting different backends like opengl. Esvg: Very early state of a SVG library based on evg. If someone is interested on any of this, please let us know. The code is available in the google code project efl-research. Maybe with the above libraries someone could think of an application that can be built on top of that. IMHO having the above libraries give us a good framework for gfx development. regards, turran. > > regards > > Vincent > > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
