Carsten wrote:
>> Anyway... Since you're still thinking about all this, and
>> since this has already been discussed at bossa, I'll drop the issue.
>>
>
> there is always room for input and discussion. until someone actually knuckles
> down and starts doing this, discussion is good as it means we will explore all
> the use cases, corner cases, issues etc. you did bring up the good point of
>
Ok, I'll give you some further 'input' on all this. :)
Part of the problem here is that something as large and
important to evas as this needs further public discussion...
and mentioning decisions/discussions by an unspecified 'we',
or possible feature requests by 'clients', is not a good way to
get this done.
I also know that adding any of this to evas is going to
mean a fairly large re-working of the image internals (among
other things), and that although a general 'filters' mechanism
is a very powerful thing, there are many, many aspects here
that need to be considered carefully.
Now, despite the discussions that were done at bossa, it's
clear to me that not everyone there seems to have the same idea
as to just what was decided - if anything.
First, it seemed that 'filters' were to be a new type of
evas object which were to be used via the current 'clipping'
api - at least that's what I thought was being proposed, and
you, raster, did as well.
Gustavo then mentioned that no, it was to be thru a similar
mechanism, but not actually as clip objects.
Finally, raster then further mentions something which seems
somewhat like some other vague stuff I'd mentioned as well, but
nothing seems particularly clear either.
No mention is made of any real api for defining these 'filters'
or how to deal with a variety of things like image-fills/borders,
or with smart objects (apart from a vague remark about adjoining
parent filters to members), or how to best implement any of this
with the various engines (apart from some vague remarks about
gl shaders and a gallium3d lib), or how to represent these things
for use with things like edje, etc...
In short, it's all been mostly a lot of vague nothing.
So, does anyone have anything more concrete to propose here?
Perhaps some further specifics discussed at bossa? If not, then I
will suggest some.
jose.
PS.
Some here would like to have ultimately flexible 'filters'
defined via some cpu&gpu supported "shading language" (a kind of
gfx scripting mechanism), but I seriously doubt that anyone here
is going to spend the time and effort required to design and
implement such a thing for evas. Thus, if evas' filters/transforms
system is designed exclusively around such an approach, it would
mean a hard dependence on eith gl-shaders or gallium3d or some
such lib that would offer this functionality.
I believe this should be an option.. ie. an optionally
compiled, loadable ability, not a built-in requirement for evas
just to allow for geometric transforms, especially since these
are so easily obtained with software and readily supported in
xrender and gl.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
