On Sun, 12 Nov 2006 12:40:37 +0100 Rene Jensen <[EMAIL PROTECTED]> babbled:
> WARNING: LONG POST AHEAD... see a mail i just replied to jose with regarding this. what we need is a way to hook native engine drawable types (pixmaps, tectures, fbo's, pbuffers etc.) to evas objects. most of the rest is already done :) > (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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
