On Wed, 25 Apr 2007 18:56:25 GMT,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote :

> 
>       Cedric's sdl engine email/patch has been hijacked into
> a bitter battle over evas and opengl :)
> 
>       Simon wrote:
> 
> > It would indeed make the engine generic but then, if the engine
> > swaps the buffers by itself, the Evas couldn't be integrated in
> > an OpenGL application: here is how we could embed an Evas in an
> > OpenGL app, if the engine wasn't swapping the buffers:
> > 
> > 1. Creation of a drawable
> > 2. Creation of a GL-context from the drawable
> > 3. Creation of the GL-engine
> > 3. While (1)
> >    {
> >       game->scene->render();
> >       evas->engine->render();
> >       game->overlay->render();
> >       swap_buffers(GL-context);
> >    }
> > 
> > Now, if the engine swaps the buffers at the end of the rendering
> > process (which is currently the case), the overlay can't be rendered
> > anymore (or you'll have to put the overlay->render() call in the
> > swap_buffers() callback, but it's kind of tricky imho)
> 
>       Ok, this assumes that the game->render() itself is rendering
> to the gl front/back buffer and that it too doesn't flush things.
> But if that's the case, then why can't the evas gl engine in question
> be rendering to a pbuffer or texture say, and then draw that to the
> main render buffer (eg. as a textured quad), and then flush things?
Indeed, it assumes that game->scene->render(), evas->engine->render()
and evas->overlay->render() doesn't manipulate directly the GL
context (for swapping or for changing the active GL-context, for
example), but I see no reason why they would need to do that.
They should behave as independant "gl objects": they should only use
OpenGL functions, and they should keep the current GL state unchanged
(this could be done easily with glPop/PushAttribs()). This is the
only way I know to do modular OpenGL programming.

About your second point, The gl-engine can render to a texture or a
pbuffer, there is no problem with this, as long as it doesn't swap the
buffers. But as raster said, it is not possible if we want to get good
performances with OpenGL, rendering to a texture is slow as hell
(don't know muck about pbuffers). And actually, it doesn't solve the
current problem at all (buffers will still have to be swapped somewhere)

>       No matter how much you want to put evas canvases into a
> gl based rendering context, you are also going to want to do the
> opposite - use gl rendering in an evas gl canvas.
Yes indeed, and this is possible with the above scheme: you
can do your gl-rendering in the game->overlay->render() function, all
the GL primitives that will be drawn in this function will be drawn
over the Evas GL canvas (you may just need to clear the Z-buffer)
> 
>       The cleanest way to do these kinds of things, wether it's
> gl based or xrender based or cairo based or your-software-routines
> or via some 3D-game-engine (or even, egods, a raytracer!), is to
> have evas engine specific buffers to draw to.
> 
>       This is why the software engines are so powerful/versatile,
> it provides a full circle - you can draw to a display target via
> the software engines, and you can draw to a software buffer target,
> and you can set such a buffer as 'data' for image objects.
> 
>       This kind of completeness would be very desirable as well,
> at least withing the context of engines driven by a given rendering
> backend - software, xrender, gl, cairo, ...
Agreed :)

Simon
> 
>    jose.
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to