Hi,
On Wed, 2009-09-16 at 13:34 +0200, Johannes Brunen wrote:
> Hello,
>
> I have some minor problems with the passive classes. I would be
> interested what other think about it.
>
> First look at the PassiveViewport class. I think this class should
> provide the following virtual function implementation:
>
> void PassiveViewport::activateSize(void)
> {
> GLint pl = getPixelLeft();
> GLint pr = getPixelRight();
> GLint pb = getPixelBottom();
> GLint pt = getPixelTop();
> GLint pw = pr - pl + 1;
> GLint ph = pt - pb + 1;
>
> glViewport(pl, pb, pw, ph);
> }
>
> That is because the Viewport base class does provide the following
> generic implementation:
>
> void Viewport::activateSize(void)
> {
> GLint pl = getPixelLeft();
> GLint pr = getPixelRight();
> GLint pb = getPixelBottom();
> GLint pt = getPixelTop();
> GLint pw = pr - pl + 1;
> GLint ph = pt - pb + 1;
>
> glViewport(pl, pb, pw, ph);
>
> if(!isFullWindow())
> {
> glScissor(pl, pb, pw, ph);
> glEnable(GL_SCISSOR_TEST);
> }
> else
> {
> glDisable(GL_SCISSOR_TEST);
> }
>
> }
>
> Now, if you have running OpenGL code outside of the scene graph that
> does work with the scissor test, you are lost at this place. On the
> other hand, the above code just leaves the fundamental task for the
> passive viewport class, i.e. setting of the viewport state.
>
hmm, these are leftovers and not in the code path anymore. The whole
handling is done in the backend. These functions are marked for
removal.
As to OpenGL code outside the scene graph. The renderaction leaves the
viewport / scissor state as it was found when window->render was called
so it should not influence what happens outside. If it does it is a bug
in the backend. Similar the outside code has to make sure the setup is
what it needs.
As for the passive viewport the pixel size information is queried from
the context during render so it relies on the app to do the correct gl
setup before calling render. So this is kind of circular, except if one
treats it as a helper for the app to setup the gl viewport state.
> Secondly, I think that the PassiveWindow class should provide an empty
> implementation for the following two functions:
>
> virtual void doActivate()
> virtual void doDeactivate()
>
> Why is that? Because on intialization as in the following code
>
> osg::PassiveWindowUnrecPtr window = osg::PassiveWindow::create();
> window->init();
>
> the OpenGL context is deactivated by the passive window base class
> doDeactivate call. Now, the passive window isn't that passive anymore.
> Actually, I have a little problem with this situation in my code, since
> I further modify gl state after the init call.
you can pass a callback to init which does the additional initial
modification of the gl state.
> Now, I have two simple solutions for the problems. At first I have my
> own EnhPassiveViewport class and secondly I can manually re-establish
> the current OpenGL context. But I think that it would be more correct to
> modify the core OpenSG code with respect to the passive object
> implementations.
that is stuck as work in progress. I'll have a look. But I'm still
not sure about some of the things involved. The problem is currently the
passive window becomes a very special case which you can't easily swap
for any other opensg window anymore and that worries me a little.
Ideally I would forbid any direct gl access to the application and
provide the infrastructure so that the app can schedule tasks if it
needs to so that the OpenSG infrastructure 'knows' when the app is
accessing the context. This works for all of the windows except the
passive one.
kind regards,
gerrit
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
