From: <jos...@ju...> - 2006-11-12 16:50:02
|
Rene writes: > ... > ... > = > 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_ Engine_GL_X11.h"). 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 changes. 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 whatever. Don't give up! Keep reading that evas, ecore, ecore_evas, edje, ewl, etk, code. :) jose. |