WARNING: LONG POST AHEAD... (Sigh) After having posted on both IRC and the webforum, I get the distinct feeling that this community has been worn down by daft requests for getting fancy window drawing using OpenGL.
This is a serious shame because now even the smallest utterance of that API makes it's author look guilty. The developers forget that end-users asking for something XGL'ish is a far cry from application developers asking for their favorite API for graphics/GLGPU programming, which they need to make video/3D applications using Ewl/Etk. However, as an application developer, I feel that: 1) Etk/Edje is perfect for the job. The efficiency is the reason I am choosing E if I can get away with it in the first place. I need a strong and themable GUI. I *LOVE* Efl's well-organized style! 2) The window manager and graphics lib should NOT squander my precious GPU cycles on needless features. If I could make a 3D in a console window, I'd do that. 3) An extra GL layer is actually another source of errors! Once I made a small 3D paint-program that used GL for the painting procedures, http://artcamilla.dk/centipede. I spend a LOT of time tracking down a bug in Windows where I use Nvidias desktop switcher. All that was drawn on my screen was a frame delayed. Turned out that when I switched off the desktop switcher or even turned off screen rotation (I have a tablet-pc), the bug dissappeared. Wasn't in my program after all. Incidently, the above mentioned program used my own OpenGL based mini-GUI. Guess why I am looking for another GUI with a strong support of themes ;-) 4) It will be hard to write any program at all in the video/3D industry without having support for OpenGL. -------------------------------- Ok, enough ranting. This is a verbatim copy of the forum post I made few days ago. By the end of this mail, I have already answered some of it: -------------------------------- 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. Without in any way claiming to be a proficient E programmer, I've taken the liberty to scout for the possibility of drawing 3D in ETK, since it appears to be a non-existing feature right now. Hope I won't make too big a fool of myself ;-) 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. So I guess that in order to get OpenGL support in ETK, three things are needed: 1) Access the Drawable for the root Evas (if using X11/GLX) or a Window (if using GDI/WGL on windows) 2) Knowledge about where in the root-evas the widget which on which OpenGL drawing should occur is placed. 3) Cooperation from ETK: It shouldn't paint anything to update that widget and it should make it possible to emit a "paint" signal so the user can emit the proper set of OpenGL commands. Getting 2. to work should be easy. Accessing the Drawable in 1 is not at all impossible either, I guess. (save the Drawable in a global var in some of the E libraries and get it through a function. As to 3., it is more of a mystery exactly how, but perhaps somebody sees the light more clearly. Before I go on, I'd like your sentiments on this request/suggestion. Presumable somebody will cry: "No way! E has nothing to do with OpenGL period! This would violate the API which is totally architecture agnostic, you ignorant philistine", which is a perfectly adult way of opening this interesting discussion. Other people may ask why I am not simply using this ...XXX... GL-widget. I certainly hope that happens ;-) -------------------------------- And a few more thoughts (and solutions) I have since made: 1) I can see a problem if Evas uses some form of buffering. Then you need to pump out the data from the GL context. This may not be as slow as it sounds on modern architectures and if the updating of the cache doesn't happen every time a single bit has been changed. 2) A spin on the above. In case Evas buffers use that cache, it is going to be hard to emit some kind of "paint" signal which will be needed to draw opengl into the canvas. However I studied Evas' code and I can see that the engine-module simply get a eng_image_draw (in modules/engines/gl_x11/evas_engine.c) which converts into a evas_gl_common_image_draw (in modules/engines/gl_common/evas_gl_image.c) In the last function, the is evident that the Image being painted is actually a GL texture. So a quick solution could be to use GL's recent Render-To-Texture mechanism (a.k.a Framebuffers) to make the Image being juggled with an actual 3D image rendered at users will (as long as (s)he remembers to tell Evas that the "image" has changed). Not the fastest solution, but not bad either. The programmer is unburdened with "paint" calls, and Evas is free to repaint and buffer as it sees fit. Responding to my own statements earlier: 1) We already have access to the Drawable from the program's main function, which sets up the environment. I missed that because it seems etk_init handles it. Thus etk_init needs to open up a bit. 2) If you use Render-To-Texture, you don't need anything from Etk except access/modification possibility of it's GLuint that holds the texture name 3) - ditto - Caveat's: 1) You still need the GL CONTEXT that get's created. For some reason this isn't dont in the main function, e.g. bin/evas_gl_x11_main.c 2) You need to be able to get the GLuint of an image. 3) This is inherently ENGINE SPECIFIC. No sense in asking for a texture-id from a cairo backend. -------------------------------- And something completely different: I have good experience with OpenGL and a small GDI/GL + X/GL cross-platform GUI behind me. I couldn't help noticing that your Win32/GDI engine files are almost empty. Just ask if you need any tips. I might be able to help. I also have a somewhat deep understanding of OpenGL Framebuffer Objects and all that "weird" OpenGL stuff. Oh, and don't use the GDI way of transferring buffered graphics data to a window (Device Independent Bitmap). Slow like hell. Either use a GL context (why not?) or DirectX. I don't know anything about GDI+ or the new stuff from MS. Ahem, I should stop talking. Regards Centipede (Rene Jensen) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
