On Thu, Feb 28, 2008 at 9:00 AM, Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> 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.
The fact that I added filter objects to Evas and not Enesim in wiki
added some discussion on IRC. I would like to have both Evas and
Enesim, because they have different constraints and time lines. I just
added Evas because I thought Jorge would add the enesim bits.
Evas is there now and lots of code base on its current state. I don't
think we'll be able to rewrite Evas on top of Enesim before getting
E17 out doors. I say that because Evas already handle lots of corner
cases that any library that wants to replace it (including its
rewrite) would have to, don't ask me for these corner cases, because
these are the ones that you just remember when you reach them. Things
are usually simple in concept, but just after you put them in "real
testing" you expose some requirements, just see Cedric's EET patch,
really simple in concept but nasty bugs appeared that need time to
fix.
That said, I also think having both is no overlapping, adding filter
objects to Evas is trying to fit it in something have HUGE walls to
work around, you will not be able to do much, our work is to find out
the minimum set of changes to Evas to support the minimum of hardware
accelerated filters. Read the wiki, you'll see I'm not proposing a
general purpose filter solution, something that would work with
software, framebuffer and like, I just want something that will enable
us to use hardware acceleration if it is available.
For Enesim it's a whole different story, we have no walls and our
job is to ensure we'll not do decisions that will put a huge wall in
the middle our our living room. We have almost all requirements
already and we know about last hardware capabilities, things like
shaders were not available before.
Evas filter objects can be understood as a temporary solution, as
a prototype for enesim work and in future as a testbed for its
implementations.
> 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.
I'm also for it, but maybe it could go outside SoC. Having one single
data library is a good thing because it will make code duplication
smaller and also things like different languages bindings easier too.
However (DON'T SHOOT ME YET) maybe we could join some efforts with
existing projects, like GLib. Maybe it's a solution, maybe it's not,
they already provide some structures we need, others we'll have to add
(like lists that support insertions in both ends with the same cost,
like evas_list). I don't know if I like this too much, but I want
to see others opinion on that.
> 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.
+1
> 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.
-0, I'm not sure this will be of much use if we have a good enesim +
ecore_$input
> (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.
not really sure, I'm for enesim using openvg, but implementing openvg
in software is not of much help.
> 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.
-1, postpone this.
--
Gustavo Sverzut Barbieri
http://profusion.mobi - Embedded and Mobile Software Development
--------------------------------------
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
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
