Hi Ricky, I'm afraid I can't help further there are too many unknowns to provide guidance.
Robert. On 19 November 2015 at 14:51, Riccardo Corsi <riccardo.co...@kairos3d.it> wrote: > Hi Robert, > > I wasn't able to reproduce the issue with as osg example. > But I've found that if just set to true the "average" flag when calling I > addUserStatsLine(), the flickering disappear. > Don't know if this is helpful, but the result just works for me. > > Regarding the drawing stats affected by the driver blocking behavior, > is the only drawback is a "fake" stats or there might be actual > performance penalties? > > Thanks, > Ricky > > On Wed, Nov 18, 2015 at 8:08 PM, Robert Osfield <robert.osfi...@gmail.com> > wrote: > >> Hi Ricky, >> >> This type of behaviour can be difficult to diagnose when you have all the >> data and software in front of you, when you only have reports from a 3rd >> party it's unfortunately next to impossible to diagnose. >> >> Since I can't determine the problem there isn't anything I can suggest. >> If you can reproduce the problem in an OSG example that you can share then >> there is chance then that others can pitch in and see if they can spot the >> cause of the problem and what to do about it. >> >> Robert. >> >> On 18 November 2015 at 17:46, Riccardo Corsi <riccardo.co...@kairos3d.it> >> wrote: >> >>> Hi Robert, >>> >>> with "flickering" I mean that the labels of my custom stats lines are >>> always showing, >>> while the numeric value besides them disappear in some frames. >>> They apparently disappear under the conditions explained in my previous >>> email. >>> This is true only for my custom stats, and not the default one updated >>> by osg. >>> (with vsync disabled things improve, but sometimes the issue is still >>> visible). >>> >>> I might try to reproduce the issue with a heavy enough osg model loaded >>> in the osguserstats example. >>> >>> As for the draw, disabling the vsync dramatically reduces the draw time >>> shown in the stats. >>> Should I live with this blocking behavior when vsync is on? >>> The only drawback is a "fake" (and misleading) stats or there are real >>> performance penalties? >>> >>> Thanks, >>> Ricky >>> >>> On Wed, Nov 18, 2015 at 6:28 PM, Robert Osfield < >>> robert.osfi...@gmail.com> wrote: >>> >>>> Hi Ricky, >>>> >>>> When you mean flickering, could it simply be that the frame timing >>>> stats is jumping between two extremes on alternate frames. >>>> >>>> In certain circumstances the driver can block and draw dispatch times >>>> can suddenly go up massively even though that actual system shouldn't be >>>> overloaded. In the example you show this is happening. It could possibly >>>> be something else on the OSG side that is blocking. >>>> >>>> As a sanity test try disabling vsync as this can change the behaviour >>>> of the driver w.r.t blocking. >>>> >>>> Robert. >>>> >>>> On 18 November 2015 at 16:20, Riccardo Corsi < >>>> riccardo.co...@kairos3d.it> wrote: >>>> >>>>> Hi Robert, >>>>> >>>>> yes for the flickering I refer to the stats on screen. >>>>> >>>>> Here's what I've noticed: >>>>> - I place my stats update between event and update traversal >>>>> - the flickering appears when I use threading models other than >>>>> singleThreaded (typically the default DrawThreadPerContext one) >>>>> AND the cull+draw time hits the frame duration time (around 16ms at >>>>> 60Hz). >>>>> >>>>> Like if the onscreen stats were "dropping" when the application >>>>> doesn't keep 60Hz. >>>>> I don't tweak the render code in any way, just a regular osg loop with >>>>> some custom code in between osg calls. >>>>> >>>>> >>>>> Side note: >>>>> the draw time shown in the stats almost always fills up the frame time >>>>> when using threading scheme other than SingleThreaded, >>>>> even if the drawing thread has little to do. >>>>> SingleThreaded scheme does not suffer the same issue (see attached >>>>> screenshot, simple osgviewer). >>>>> I presume this is due to OS + driver combination, >>>>> I'm on Win7 64bits + nVidia 970 GTX. >>>>> >>>>> Thank you, >>>>> Ricky >>>>> >>>>> >>>>> On Wed, Nov 18, 2015 at 4:46 PM, Robert Osfield < >>>>> robert.osfi...@gmail.com> wrote: >>>>> >>>>>> On 18 November 2015 at 15:14, Riccardo Corsi < >>>>>> riccardo.co...@kairos3d.it> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> in my project I'm using some custom statistics as in the >>>>>>> osguserstats.cpp example. >>>>>>> >>>>>>> In the example, user stats are updated every frame between advance() >>>>>>> and eventTraversal(). >>>>>>> >>>>>>> In my case, I was trying to update my stats between eventTRaversal() >>>>>>> and updateTraversal(), where I already execute some other code. >>>>>>> >>>>>>> But by doing so, stats do not always show up correctly - sometimes >>>>>>> they "flicker" and do not show. >>>>>>> Is the one used in the example the only one safe place to update >>>>>>> user stats? >>>>>>> >>>>>> >>>>>> The osg::Stats object that is used for recording stats uses a mutex >>>>>> internally to make sure that setting and getting stats is thread safe. >>>>>> osg::Stats itself is just a container object though it doesn't do any >>>>>> rendering so itself can't "flicker". >>>>>> >>>>>> When you say flicker I presume we are talking about onscreen stats. >>>>>> I haven't seen reports of them flickering before. Perhaps your usage >>>>>> model >>>>>> trips up the rendering code in some way. What threading model are you >>>>>> running the viewer with? Can you modify an OSG example to reproduce the >>>>>> issue? >>>>>> >>>>>> Robert. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> osg-users mailing list >>>>>> osg-users@lists.openscenegraph.org >>>>>> >>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> osg-users mailing list >>>>> osg-users@lists.openscenegraph.org >>>>> >>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> osg-users@lists.openscenegraph.org >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org