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? -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
