> > I have some experience with SDL + OpenGL and there is nothing
> > different between using OpenGL with SDL and using OpenGL with
> > an X11 window (OpenGL-wise). The only differences are the calls
> > that depends on the windowing system: the creation of the GL
> > context and the swapping of the front/back buffers. But I don't
> > think it's worth it to create an Evas engine for OpenGL+SDL.
> > It will be exactly the same as the GL-X11 engine (i.e just a
> > wrapper of the GL-common engine).
>
> agreed. in fact the sdl engine is strange. it allocates sdl
> surfaces for images - but really doesnt do anything more than
> the software engine. there is not any good reason for this, and
> really the sdl engine shouldnt need to be any more than just an
> sdl wrapper handling the windowing system interfacing and display
> of ARGB32 data to the screen - the rest can be the software engine
> as-is.
Yes. Maybe Cedric intended to use sdl provided compositing
functions of some sort but had problems with it for some reason
(maybe due to premul data), and the forgot to remove the use of sdl
surfaces?
Actually, it would be good to see the direct-fb engine be
more like this.. it's a bit 'klunky' right now (the dfb one).
> > Actually, I don't think there should be a GL-X11 engine in evas
> > at all. Just the GL-common engine should be enough. Then all the
> > code to create the GL-context and to swap the buffers (that is
> > to say, all the code that is currently in the GL-X11 engine)
> > should be moved to Ecore_Evas imho. This way, if we'd like to
> > use OpenGL+SDL or OpenGL+Win32, there will be no need to create
> > a new Evas engine. We would just have to create the window,
> > the GL-context and to use it with the GL-common engine of Evas
> > (all of these could be done in Ecore_Evas). And it will make it
> > possible to use Evas in your own OpenGL app which already has
> > its own GL context: for example, you could use Evas for the
> > GUI of an OpenGL game, which could be really cool imho :)
>
> i disagree. currently the engine does the swaps because that is
> the onyl sane way to get performance with gl. in theory it should
> render updates like the software engines do - render the update
> regions to a pbuffer/texture then copy to the frontbffer instead
> of allocating a whole backbuffer for the window. the problem is
> that if you expose this, this mechanism is no longer tweakable by
> the engine. the software engines dont force you to do anything
> special before or after rendering to make them display, and the
> gl engine shouldnt either imho.
I'm not sure that I follow Simon here.. Why couldn't one
also do the same with say Cairo as a 'renderer' rather than gl?
What would one gain over say having an extension of the engine
that allowed one to set engine specific 'buffers' as image obj
'data' (that one can then draw to)?
One may need to render to more than just the display target,
as you mention - in fact I'd say that's unavoidable for certain
things - and then you'd also need to expose the 'buffer'..??
Nevertheless, there's something to be said for exploring
this issue of "engine = renderer + display-target" in evas.
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
