[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Putting GL-textures into Etk, Evas, bla bla... How to ch oke a horse with words.
> I've learned that OpenGL requests falls in two camps this place:
> Those for a way to put Evas into OpenGL (for kicks), and those
> for a way to put OpenGL into Evas/Etk (for making any kind of
> serious multimedia program). This post belongs in the latter camp.
Ummm... If you know ANYTHING about OpenGL then you know more
about it than I do.. Cartsen will be better able to comment on the
evas gl front, and the ewl/etk camps on them.. but let me see if I
can give you something quickly here.
> Basically all that is needed to be able to draw using opengl in
> X is the creation of a GL context using GLX. The only thing required
> is that you have a handle to an X drawable (Window or Pixmap).
> I can see that in E getting this handle is less obvious, since E is
> unaware of a specific render-backend. Opposite GTK which has an
> X Window for each widget, ETK renders each element directly to a
> buffer, and only this grand superbuffer has an associated Window -
> if using some kind of X11 backend of course. If I read the code
> correctly, the Evas software-X11 backend actually renders to a
> pixbuf in shared-memory.
> So far so good. I traced this Drawable to a function called
> 'eng_setup', which is handed an X Drawable (amongst other things).
> Though I can't see where this Drawable is created since I don't
> know who CALLS eng_setup, I guess it would still be possible to
> get the super-drawable somehow.
In evas, if you're using an x11 drawable as your target
display end, you can use the software-x11 engine, the xrender-x11
engine, the gl-x11 engine, ...
With any of these engines, it's you that needs to actually
give evas the display, drawable,... target you want to draw to,
and that's done by setting up the "info" of each evas canvas via
the evas api func "evas_engine_info_set" (this is what calls the
internal eng_setup function). This requires that you include a
certain header file for each engine type that you use (eg. "Evas_
Each of ecore_evas, ewl, etk give you higher level interfaces
for doing this.
Now, as to doing any sort of 3D rendering into an evas...
Well, you'd need evas to support loadable object types in order to
do this efficiently for highly dynamic 3D stuff. I don't think the
evas gl engine should export its gl/glx contexts.. it's a rather
convoluted affair internally right now.
But there are a couple of 'simple' things one could do.
1. For 'static' kinds of 3D stuff, I believe there are
various 3d scene-description file formats for defining such..
You could try writing evas image loaders for one (or more) of
these. You'd render them to whatever you can that then allows
you to transfer it to an argb32 buffer and set that as the image
data. For 'scalable' formats there's already in place a mechanism
for specifying the pixel size at which to load the image.
2. For moderately dynamic 3D stuff, you can use OpenGL
to render whatever to a texture or pixbuffer somehow, and then
again get this to an argb32 buffer and set that as the data of
an evas image object.. updating regions as need be for 3D state
Again, this won't be terribly efficient, but it may be
fine for moderately dynamic stuff (having evas image objs support
render-pre/post callbacks will help a bit).
You can then work this into ewl/etk in various ways,
maybe via a separate 'evas_3D_utility' lib they could use, or
Don't give up! Keep reading that evas, ecore, ecore_evas,
edje, ewl, etk, code. :)