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

        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'.
        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).

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

_____________________________________________________________
Can't pay your bills?  Click here to learn about filing for bankruptcy.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nfvZ1HP2N7idMqB8psDhtwnNzca8Owk4iEEfc4EysHx9ahK/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to