On Fri, 6 Apr 2007 15:21:52 +0200, Cedric BAIL <[EMAIL PROTECTED]> wrote : > > I did visit the sdl website, and there seems to be mention > > of using "OpenGL with SDL"... Is it possible to maybe also have > > a "gl_sdl" version of the engine.. ie. one which would presumably > > use some gl rendering? > > I did think about that also, but I must have some priority. So first > I want to have an Ecore with all others EFL running cleany with the > software_sdl. So it's definitively possible in my opinion, but not > really on top of my TODO list :) 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).
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've already discussed this with raster and he told me the only reason to bind the GL-Context with the Evas engine is because the context is stateful and if the context were to be shared between the Evas-engine and the application code, the application could change/corrupt the context's state and it could break the Evas engine. That's a good point, but actually, there is a way to save/restore the current state of a GL-context with glPushAttrib(GL_ALL_ATTRIB_BITS)/glPopAttrib(GL_ALL_ATTRIB_BITS). It saves the current viewport, the current matrices, and all the current states. I just don't know if it is efficient and if it's available on all the GL cards. Raster, what do you think about creating a generic GL-engine for Evas (with the glPushAttrib()/glPopAttrib() thing), and to move the existing code of the GL-X11 engine (creation of the context and buffer-swapping) to Ecore_Evas_GL_X11? If this is ok, I'm willing to do it if you want. Regards, Simon TRENY <MoOm> > > Cedric > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief surveys-and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
