> 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).
>
I should've added that such an addition is not, strictly
speaking, required... especially if one restricts filters/transforms
to be of "surface" types - it'd just make things a bit simpler and
more efficient for everyone.
-------------------------------------------------------------------------
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
