On Mon, 21 Apr 2008 01:04:55 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> On Sun, Apr 20, 2008 at 5:19 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > > > > > > > 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. > > > Jose, > > I'm running out of time to reply to all of these ideas, I expect to > get back some development time after the company I started start to > calm down on the "real world side" (we were getting infrastructure and > like, phone, network, ...). But I really fear to loose all these > ideas. I know we have mail archive, but it would help a lot if one > (you, others) could move this to Wiki and do some structure, much like > Dresb and I did for some ideas. Then people can check when we're about > to start working on it. > > What do you think? I think that's an excellent idea. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
