Gustavo 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 ....
>
> 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
> ...
>
> 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.
I'm not sure what "getting e17 out" or enesim have to do with
the particulars of the evas filters/transforms proposals you added to
the wiki.
How much have you looked into this? You don't need OpenGL
or "gallium3D" for any of the things mentioned above, and in fact
it may well be about the same, or worse, in many circumstances to
do things via those libs - even with decent drivers.
Also, what you proposed was a very generic filter pipeline
mechanism, which though nice in theory may well be fairly counter-
productive or useless to have in practice for most cases that evas
is applied to. You don't need to have a filter mechanism rivaling
Photoshop built-in to evas, or requirements that there be "shaders"
for it to work, and there are more aspects here than just being able
to 'do the gfx', hardware accel or not.
That said, I think it's great that you want to see things
move forward and all... and who knows, maybe there's lot one can
gain out of trying out your approach to this. In the end though,
Carsten is the maintainer of both evas and edje, and something as
large as this would be best discussed with him.
-------------------------------------------------------------------------
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
