On Mon, 30 Apr 2007 12:34:25 +0900,
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote :
> 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).
Actually, what I really want is a GL engine that is not aware of the
rendering-target, i.e. an engine that can render indifferently to the
backbuffer, to the fronbuffer, to a texture, to a pbuffer... and
independently of the windowing system used. Here would be the different
schemes to do these things with this generic GL engine:
Backbuffer + double-buffering:
1. Creation of a GL-context with double-buffering
2. Creation of the generic GL-engine
3. while (1) { engine->render(); swap_buffers(GL-context) }
Frontbuffer + single-buffering:
1. Creation of a GL-context with single-buffering
2. Creation of the generic GL-engine
3. while (1) { engine->render(); glFlush() }
Rendering to a texture:
1. Creation of a GL-context
2. Creation of the generic GL-engine
3. Creation the target texture
3. while (1) { engine->render(); glBindTexture(target-id);
glCopyTexImage2D(...) }
I don't know how pbuffers work, but I'm pretty sure there is a similar
scheme to render to a pbuffer.
The only assumption that is done for these schemes to work is that the
engine does not change the draw-buffer (with glDrawBuffer()). It should
use the default draw-buffer. But I see no reason why the engine would
like to do that. The only place where it is done in the gl-common is in
evas_gl_common_swap_rect() which would be useless with a generic
engine (and actually, it's not even used right now).
>
> > 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.
As I said above, with the generic engine, there would be no need for a
gl_gl engine. Only one engine would be needed for all the rendering
targets. There would be no need to create a new engine each time we
want to render to a new target (currently, it would be a mess if
we want to support a lot of targets: gl_x11, gl_win32, gl_xcb,
gl_pbuffer_x11, gl_pbuffer_win32, gl_texture...).
And the gl_gl engine would not even be usable with a lot of configs
since it requires a powerful graphic-card to render EFFICIENTLY
to a texture/pbuffer.
The only drawback I can see with the generic engine is the assumption
that it doesn't change the default draw-buffer. But I really think its
worth it when you look at what it would bring.
Simon
>
> > >
> > > > 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
