The minor issues I had with doing it externally are (the way I see it) : - the crop needs to be applied to the real (internal) size of the video/image/whatever (emotion_object_size_get/evas_object_image_size_get), you can't use the size of the evas_object_size_get, I don't know of a generic evas_object_original_size_get - once you have applied the crop, the image/video size returned by those functions should be affected
This code IS just a rectangle that clips the object, it's only done inside the smart object My question is : do other objects ~really need~ cropping? We know here for sure that video does (= it's a real world use/need for us... remove black bars or show video on a screen-wall) I don't think it's wrong to have some features limited to some object. For example, only evas_object_image has "border" functionality, right? Of course if you want to spend (waste? :-P ) time implementing a completely object agnostic way of cropping, enjoy yourself, it definitely see how it would be better. I just won't have time to do that ^^ On 11/18/10, Carsten Haitzler <[email protected]> wrote: > On Thu, 18 Nov 2010 10:28:29 +0100 Hugo Camboulive > <[email protected]> > said: > > if you just use a rectangle and set it as the clip object.. this is not just > generic for emotion.. it's generic... for ANY object. :) > >> 1. ok for left/right/top/bottom, I think I got the a/b/c/d from the >> sketches I did when I was trying to get the resizing formula correctly >> ^^ >> 2. just wanted to be generic, if you clip by 0 the computed size in >> resize/move should be the same, as you said it does not matter much >> 3. oh yeah indeed, only color the image xor the clipper >> 4. I know there is some cropping abilities in VLC, but it does not >> work really well (you can crop only by multiples of 8px, if you don't >> VLC adds ugly green bars, additionally I think from the command line >> you can only crop to predefined ratios, so it's kind of broken) >> The only thing this patch adds is a clipper+some resizing, so I don't >> think it will add a big cpu overhead. Most of the time is already >> taken by resizing the image (with smooth scale), and that's already >> happenning even without a crop, as soon as the video size is different >> from the destination size. >> The advantage of this method is being generic (will work for any engine) >> >> On 11/18/10, Carsten Haitzler <[email protected]> wrote: >> > On Wed, 17 Nov 2010 13:22:39 -0200 Gustavo Sverzut Barbieri >> > <[email protected]> said: >> > >> >> On Wed, Oct 6, 2010 at 9:18 AM, Hugo Camboulive >> >> <[email protected]> wrote: >> >> > Hi guys, >> >> > >> >> > This patch adds support for video cropping in emotion, if anyone's >> >> > interested. You give it the number of pixels you want to crop on each >> >> > size (relative to the original size of the video) >> >> > We use it to remove black bars from a video or do a video wall with >> >> > multiple screens, it works fine even with our low power machines. >> >> >> >> Hi Hugo, >> >> >> >> Going through my backlog I've found this unreviewed code. Sorry taking >> >> so >> >> long. >> >> >> >> I wonder why you chose the names a,b,c,d for left,top,right,bottom. >> >> Please rename it to proper names, if you want to keep single letters, >> >> fine, but at least use l,t,r,b. I'd also follow edje's sequence: >> >> l,r,t,b. >> >> >> >> I'd also keep sd->crop.clipper only whenever there is a clipper in >> >> use. But that does not matter much. >> >> >> >> setting the color on smart_color_set() of the clipper will have the >> >> wrong result, it will apply twice: once due the clipper, another due >> >> the image being colored. >> >> >> >> All in all I wonder if there is no better way to do this, like passing >> >> this information to the engines and letting them implement in a >> >> possibly faster way. This could be a fallback system if not >> >> implemented by engine, or engine could use it. >> >> >> >> Raster, do you have any knowledge of that kind of feature in xine? I >> >> remember mplayer has builtin cropping filters. >> > >> > i don't remember any such thing in xine. as such given the fact we have >> > things >> > like motion vectors, the only optimization this could do is skip >> > yuv->rgb in >> > the software engine for cropped out sections. the video decode still >> > will >> > happen. as such just using a clip rect object and clipping to it will do >> > the >> > job just as well minus the above skip-ability for software. >> > >> > -- >> > ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> > The Rasterman (Carsten Haitzler) [email protected] >> > >> > >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
