[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 choke a horse with words.

On Sun, 12 Nov 2006 12:40:37 +0100 Rene Jensen <centipede@takhis.net> babbled:


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)    raster@rasterman.com
Tokyo, Japan (東京 日本)