On Wed, 25 Apr 2007 01:17:56 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> 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) }
but by doing this you ASSUME the mechanism for updating IS a glxswapbuffers -
what if it isn't? what if we change it to do what i said (render to
texture/pbuffer, then copy that to the frontbuffer) - maybe it might do things
differently based on the driver (some drivers might be able to accelerate this,
some may not).? the gl engine in this regard is no less limited than the
software_x11 - EXCEPt it doesnt allow alternate drawable targets (pixmaps).
what YOU want is the ability for the gl engine to render to a texture or
pbuffer - and you get to specify that texture/pbuffer. that is what you really
want. it would then work no differently to the software and xrender engines
that can have pixmaps specified as targets (as a pixmap and window are the same
for rendering purposes here).
> 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 don't think we should change the gl_x11 engine - maybe what you want is a
gl_gl engine - it can use the same gl common core that already exists but simply
the rendering target is either a texture or a pbuffer - the calling app then
can take that and copy it to the screen however it likes - that would give you
what you want. it would also be clean, keep the current gl_x11 engine the same
etc. etc.
> >
> > > 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
