>      We've mentioned the semantic interpretation of these 'surface'
> filters acting on an object as _functionally_ equivalent to first
> rendering the object to a buffer 'surface' and having the filter
> act on that surface... Ok, how about we make this former action
> available thru the evas api - ie. have an api func that allows for
> one to render an evas object to an evas image object, say of the form:
>
> void
> evas_object_draw(obj, dst_im_obj, x, y, w, h);
>
> or something like that.
>
>      This would be an immediate-mode call, with the semantics being
> that the obj is drawn in its current state to the dst_im_obj's data
> surface, ie. composite the obj with whatever the state of the dst
> image surface (which can be argb data, a gl texture, an xrender pict,
> etc).
>

      Actually, a better form for this might be:

void
evas_object_draw(Evas_Object *obj, Evas_Object *im,
                 Evas_Coord x, Evas_Coord y, Evas_Rectangle *clip);

      This form is useful when the src obj has a transform since
the src 'origin' can be positioned at the dst image x,y coords, and
the drawing restricted to the specified dst im clip region (if the
clip is there, or over the whole image surface area if not).



-------------------------------------------------------------------------
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

Reply via email to