[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 <email@example.com> 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
> 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
> 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 -
> 1) You still need the GL CONTEXT that get's created. For some reason
> this isn't dont in the main function, e.g.
> 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
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)