On Wed, 25 Apr 2007 17:19:25 +0200,
Sebastian Dransfeld <[EMAIL PROTECTED]> wrote :

> Simon TRENY wrote:
> > On Tue, 24 Apr 2007 17:33:11 -0500,
> > "Nathan Ingersoll" <[EMAIL PROTECTED]> wrote :
> > 
> >> On 4/24/07, Simon TRENY <[EMAIL PROTECTED]> wrote:
> >>> from this:
> >>> 1. Creation of a drawable
> >>> 2. Creation of the GL-engine from the drawable
> >>> 3. While (1) do { engine->render() }
> >>>
> >>> to this:
> >>> 1. Creation of a drawable
> >>> 2. Creation of a GL-context from the drawable
> >>> 2. Creation of the GL-engine
> >>> 3. While (1) do { engine->render(); swap_buffers(GL-context) }
> >> Is there any reason that this could not be controlled simply by the
> >> engine info passed at setup time?
> >>
> >> If the info contains a GL-context, use the passed context and don't
> >> call swap_buffers, otherwise use the current behavior. Seems like
> >> you would get the best of both worlds and the usual case would
> >> still be just as simple as it is now.
> >>
> > Actually, the GL-context is almost only used to swap the buffers, so
> > passing the context to the engine if the engine doesn't call the
> > swap_buffers() functions is not really coherent I think.
> > And since there is no generic GL-context type (each windowing system
> > implements its own type for the GL-context: GLXContext for GLX,
> > HGLRC for Windows...), we still couldn't have a generic GL-engine
> > (we would still need one GL-engine per windowing system).
> 
> Implement swap_buffers as a callback?
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)

Simon
> 
> Sebastian
> 
> 
> -------------------------------------------------------------------------
> 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