Hi Robert and Rafa, I just see this change was introduced by Christian Kehl ( http://comments.gmane.org/gmane.comp.graphics.openscenegraph.cvs/12859) but probably he had a little mess in his computer when doing this change (As he also stated later ). It is possible it might be not necessary.
Maybe Christian can comment something. Cheers. 2015-06-09 7:01 GMT+02:00 Rafa Gaitan <[email protected]>: > Hi Robert, > I did a couple of builds one for MacOSX 10.10 and for android gles1. For > macosx everything worked so far but for android I'm getting this error > using the toolchain: > > osg-trunk/include/osg/GLDefines:35:21: error: conflicting declaration > 'typedef GLfloat GLdouble' > > I suspect this is the same problem others has spotted. I think you > suggested to do a better identification in cmake, or maybe just check if > the symbol already exists in that header. I'll try to provide a fix later > today. > > Regards, > Rafa. > > > El lun., 8 jun. 2015 a las 20:01, Robert Osfield (< > [email protected]>) escribió: > >> Hi Jannik, >> >> A quick reply as I am replying on my phone. My intention was to introduce >> the same technique as osg::Node::asTransform() to avoid the dynamic cast, >> but only do this if there was a noticeable performance regression. >> >> The 20% regression you've seen could qualify. Is this with a release >> build? >> >> As general note, I suspect you are over using callbacks. >> >> Robert >> On 8 Jun 2015 17:16, "Jannik Heller" <[email protected]> wrote: >> >>> Hi Robert, >>> >>> I tried my application using the latest trunk and didn't notice any >>> functional regressions. >>> >>> However, I did notice a performance decrease in the Update phase of >>> about 20%, compared to OSG 3.2.0. This had me a bit concerned, so I digged >>> through the changes and found commit >>> https://github.com/openscenegraph/osg/commit/e967420323bb6e500425144cb305cf8060c1c515 >>> . >>> Since that commit, we now get *four* dynamic_cast's per frame and >>> NodeCallback, which I suspect is causing the slowdown. Two dynamic_cast's >>> are in NodeCallback::run, then another two in NodeCallback::traverse. >>> >>> Changing to the non-deprecated Callback instead of NodeCallback gives a >>> slight improvement with now just two dynamic_cast's in Callback::traverse, >>> but still isn't optimal. >>> >>> Ideally, the application should be able to decide on the level of safety >>> vs. level of performance it needs. If a Callback is only intended to be >>> used on Nodes, there is little point in dynamic_casting to Node every frame. >>> >>> I think I can workaround the casts by using a custom class derived from >>> osg::Callback as the base class for all my node callbacks. Still, it's >>> quite a peculiar situation that does affect all users of the OSG. >>> >>> I guess my question comes down to, are there any plans on optimizing the >>> Callback code before a final 3.4 release? If you aren't convinced, I can >>> throw together a repro case and some profiling data, but I think the impact >>> of 4 dynamic_cast's per frame and NodeCallback should be obvious. >>> >>> Cheers, >>> Jannik >>> >>> ------------------ >>> Read this topic online here: >>> http://forum.openscenegraph.org/viewtopic.php?p=63985#63985 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- Jordi Torres
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
