[osg-users] user stats update

Riccardo Corsi riccardo.corsi at kairos3d.it
Wed Nov 18 09:46:49 PST 2015


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.osfield at 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.corsi at 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.osfield at gmail.com
>> > wrote:
>>
>>> On 18 November 2015 at 15:14, Riccardo Corsi <riccardo.corsi at 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 at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151118/4b92e2e1/attachment-0003.htm>


More information about the osg-users mailing list