On Mon, 10 Mar 2008 06:31:51 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > I have a question for you on this though: I imagined having > > > 'native surface' image obj api given in each of the engine headers, > > > but you added a generic evas api for it.. What exactly do you have > > > in mind here? eg. say with gl-textures? > > > > literally evas exposing the engine drawing routines for that engine - > > generalised tho. gl i would expose as a generic api from a evas-3d > > lib on top of a native surface, but it would just abstrait to either > > software mesa or direct hardware opengl, so it'd work in a software > > canvas, just slowly. > > Ummm.... I'm not sure I follow you here at all. What you've > mentioned above seems far more reaching - not quite just dealing with > implementing image obj 'native surfaces', which is what I was wondering > about here. > Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give > their own views here as well, but let me just be a bit more specific as > to how I'd imagined this and see if it makes sense. engines have draw functions, like "draw line" "draw polygon" "draw image (src rect, dest rect, scale mode)" "traw text with font X" etc. etc. - these are internal between evas's canvas core and the engines. this is not exposed. if a smart object or "Custom evas object" can have access to these to draw - then either they can draw to a surface (image) using them OR they can draw directly to the canvas when an update render happens (and they get their paint() callback called - doesn't exist now, but hypothetically). > By 'native surfaces' I'd meant things like xrender pictures, > gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- > renderer specific 'buffer surfaces'. yup. > One'd then have get/set functions for image objs of 'similar' > evas engines (xrender-x11, gl-x11,...), along with various specialty > funcs to query whatever extra stuff specific such 'surfaces' might > have (eg. wether a gl texture is an nv-rect, its actual size, etc). > Ideally, there would also be given a means to convert such surfaces > to argb data (wether exposed or just internal). all images at some point use a native surface. software engines share the native surface with the original argb pixel data :) > I'd imagined these funcs in each engine header, nothing at all > in the general evas api, and one would implement the funcs in the > engine modules, likely via the use of a new 'object function' to get > an evas object's 'engine_data'. > > Or at least, that's more or less what I envisioned for these. > > Then go from there and build things like an evas-3D lib if > desired.. possibly dependent on gl but able to render to any evas by > say rendering to a gl buffer and getting argb data if need be, or some > other way.. > > But what I was curious about was what exactly you had in mind > with your: > > typedef struct _Evas_Native_Surface Evas_Native_Surface; > /**< A generic datatype for engine specific > native surface information */ > > EAPI void > evas_object_image_native_surface_set(Evas_Object *obj, > Evas_Native_Surface *surf); > EAPI Evas_Native_Surface * > evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will then take the target-specific "native surface" and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. -- ------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
