On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> 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). 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. > 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'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. and the above too - now ive been thinking about it :) > 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. well really glpushattrib/pop should get used anyway. it would really save the gl engine needing to keep its own state shadow. as above - this introduces problems. > 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 > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
