Ok, let me continue where I left off last time.
We have these various kinds of notions for possible 'filters'
in evas (there are others as well, including ones that might involve
time, ie. animation related ones), but most people here would seem
to want something along the lines of (2) above, ie. filters as certain
kinds of modifiers of objects (or of rendering an object). This is
still broad since one can have filters which modify certain types of
objs and not others... but most here would at least want filters that
modify geometry and/or pixels.
As these can be interpreted as modifying surfaces which hold the
result of rendering 'objs', one could use this to extend such filters
to modify any renderable object - albeit not necessarily in a way
that might be 'natural' to the given object.
This brings up semantic issues about the possible kinds of apis
that one can use for filters.
If a filter is something that can be 'applied' to certain
types of objects thus obtaining an implicitly modified version
of the same object (or another obj of the same type), or if it's
something that can modify the way that a given type of object
is rendered, then any notion of chaining or composing of filters
should satisfy a kind of associativity property and thus lead
to a specific interpretation.
For example, let's take the original idea of using filter
objs that one can use as 'clippers', and let's say we have an
image obj which is clipped by a rect obj, and that rect obj is
in turn clipped by a geometric transform obj (say a scaling
or rotation).
Many would think the result of this would be to render an
image which is clipped by a transformed rectangle.. but that's
actually incorrect. In order to satisfy associativity, the result
would have to be the same as first rendering the image clipped by
the rect (to a buffer), then transforming that result and render it
- ie. a scaled or rotated version of an <image clipped by a rect>,
NOT the image clipped by a <scaled or rotated rect>.
Any attempt to break semantic rules such as associativity
leads to the need for further logic for determining what to do
at which step of a sequence... and makes it difficut to decide
when one can 'break out' of a chain and render to buffers or not.
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.
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
