On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote :
> 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 see what you mean, and actually, it's "just" a design problem. But the
thing is, because of this design issue, the GL engine is far more
limited that what it could actually do. The only thing we would need to
make it as powerful as it could be would be to change Ecore_Evas_GL_X11
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) }
Indeed, the engine would no longer be "self-sufficient" since if you
don't swap the buffers, nothing would be drawn (actually it would still
be drawn on the backbuffer, but not on the screen), but if you see the
engine as GL object, these new steps make sense.
And I think accepting this design-problem is worth it if you look at
what it would make possible:
- Since the engine would behave as a "GL-object", you could insert
one or several Evas-es in your GL programs, meaning you could use
for example, Evas in a 3D game to render the HUD, or in a 3D modeler
to draw the the GUI and *more important*, I could use Evas in
Egloo... which could be really cool, from a totally selfish point of
view :)
- We would also be able to draw GL primitives over an Evas (as long as
it uses the GL-engine), which was the subject of a thread on the
Dev-ML some months ago.
- The GL engine would be totally portable and independent from the
windowing system used, so we could use it with Windows, SDL, XCB,
XLib without changing one line of code. Otherwise, we would need as
many Evas enginges as there are windowing systems that we want to
support.
So, can I just ask you to reconsider this? :)
Simon TRENY <MoOm>
>
> > 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
> > >
> >
>
>
-------------------------------------------------------------------------
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
