> 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?
>
>
No other suggestions or comments yet? :)
Before I suggest some possible approaches here (and frankly
I'm torn between several - ranging from conservative to fairly
radical ones), let me make some further comments on this.. just
for fun.
I've mentioned before that one needs to have strict typing
of 'filters' that operate on evas objects, and that one type
that can be taken to apply to all renderable objects are those
filters which operate on image surfaces - ie. which are functionally
equivalent to first rendering the obj to a buffer surface and then
applying the filter to that (and eventually compositing the buffer
surface to a dst surface).
Let's agree to call such filters "surface-filters". We know
several such that are commonly used - blur, bumpmap, convolution
kernel derived, simple color modifiers, etc.. and one other kind
that's often found are the simple 2D geometric-transform ones.
We can define these from a given 3x2 matrix (normally used to define
affine transformations), or more generally from a 3x3 matrix (for
projective transforms of 2D space).
However, given say a 3x2 matrix, one can also define geometric
transformations on 'vgfx' kinds of 'objects' by operating on their
vertex data, and lets call such kinds of filters "vertex-filters".
If we're given a 'vgfx' kind of evas object - say a polygon
or a rectangle, we may then consider 'geometric transforms' (from
say a given affine 3x2 matrix) via these two different kinds of
filters, the "surface" and the "vertex" ones... The results will
not always be the same.
Should one also consider these kinds of "vertex" filters for
evas objects which have some 'vector' aspect (eg. for rect objs,
or for poly objs)? And if so, how should one express these two
different types of filters via the api?
You might say: "No. Who cares... evas is mostly a raster based
canvas lib.. or at least that's the most commonly used object - image
objects..."
Unfortunately, evas image objects are not really like raster
surfaces at all.. in fact, they behave more like rectangles which
have been given an image as a "fill pattern" (or fill texture) which
is set to a repeat extend (or spread) mode by default!
So, should one consider these kinds of "vertex filters" in evas,
or not?
I'll give you my answer to that: NO, I don't think one should.
I don't think they're needed or desirable for most of the things
that people want to do (but I won't go into details as to why I say
that for now).
PS.
Here's a distantly related issue though: One of the most common
things that people want to do with images is to rotate them (possibly
in a 3D perspective way), flip them, blur them, etc. How can one make
it easy to express such things for evas image objs (with filters) via
the api?
I'll give you my own partial answer to this as well - an answer
that isn't really mine but rather is from a suggestion due to raster,
and that is to: Add a "fill policy" flag with two possible values,
say FILL_POLICY_EXTEND and FILL_POLICY_SCALE.
The former (extend) is the current behavior, wherein an image
is scaled to the specified fill size and then that fill extends (from
the specified fill origin) to cover the image object size (repeating
only for now), ie. image objects act like rectangles with the image
itself as a fill pattern for the rect (the object region).
The latter (scale) fill policy will ignore any "fill" properties
and instead the image will be scaled to fill the image object size,
ie. the image object now acts like a surface which has the image
scaled to fit.
This makes it very easy to deal with most uses of images where
one wants to simply "transform an image in a certain way", and not
worry about fill pattern sizes, transforms, extend modes, origins,
and also object transforms - ie. when one wants an image obj to be
like an image, not like a rect with an image as fill texture.
For example, if you wanted to say "rotate an image", or just
"blur an image", ... then with the current semantics of image objs
you'd have several ways of setting a filter on the image obj and/or
on the fill, as well as setting particular fill sizes and origins
and obj sizes... all cumbersome and inefficient.. one really just
wants to transform or blur the image obj and be done with it - and
that's what such a new fill policy would allow.. for image objects
to behave like image surfaces (subject possibly first to a scaling
of the image to the object size).
-------------------------------------------------------------------------
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
