> This is the kind of thing that makes 'chaining' of arbitrary
> filters a problem unless very strict semantic rules are followed,
> and an api used which is able to naturally represent those rules.
>
> .... I'll continue this a bit later, but please do jump in
> with comments or whatnot if you see fit.
>
>
In order to get a filter api that provides an un-ambiguous,
intuitive interpretation for things, we thus need to separate this
from the existing 'clipping' api - even if the 'filters' one might
be similar, it still really needs to be separate (it'll also allow
for greater flexibility if desired).
One also really needs to make sure that the 'filters' are
typed sufficiently so that it's clear that one's dealing with
filters that modify a given object type, or that modify 'surfaces',
etc. (of course one can consider rendering an object as a kind of
filter on surfaces, with the obj to be rendered to the surface
as providing part of the data that defines such a surface filter).
Without that, we have the general kind of ambiguity faced with
certain common filter notions like geometric transforms or coloring,
where one has to decide somehow whether to interpret the effect of
the filter as acting on a buffer-surface rendering of the object, or
otherwise.. and this is not something unique to smart-objs.
For example, in something like transf > blur > transf > polygon
the first applied transform could well be interpreted as acting
on vertex data, but the last applied one would likely need to be
done on surface data - ie. transform a buffer surface that holds the
result of blurring a rendered poly (until someone comes up with vertex
data for blurry-polygons). Consider implementing the general case of
this kind of thing, with arbitrary chains, with loadable filters, with
any object... unless you have strict typing mechanisms and composition
rules.
So long as we maintain strict typing of filters, and semantic
rules for filter composition, we have few problems.. otherwise, one
has to be more careful in order to resolve possible ambiguities.
And as soon as one starts to allow for general/loadable kinds of
filters, then one really *has* to have strict typing notions.
Whether it's just restricting things to abstract geometric
transforms and surface (ie. image) effects, or something more general,
one needs to know exactly what one is working with.. a vague 'filters
for evas objects.. We can do anything!' idea is just going to lead to
an absurd mess.
So, what kind of api should be provided for 'filters for evas
objects'? And how can general/loadable such filters be defined and
obtained?
Gustavo has given one possible suggestion (still needs the
issue of general/loadable ones addressed, and may want to replace
the 'set' with an 'add', or even an 'append/pre-pend' and others).
Does anyone else have another?
-------------------------------------------------------------------------
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
