[osg-users] High event times

[Robert Osfield]

Hi Matthias,

It might be sufficient for us to just toggle on the resize check when the
configure event arrives.  If you've added this already then just send the
changes to me and I'll do review and have a bash at retracing my steps back
in the Spring when I was resolving the original bug.

Robert.

On 2 November 2015 at 18:44, Mathias Fröhlich <Mathias.Froehlich at gmx.net>
wrote:

>
>
> Hi Robert,
>
>
>
> On Saturday, October 31, 2015 18:02:24 Robert Osfield wrote:
>
> > I have had a look at the revision and vaguely remember hunting double a
>
> > long time troublesome bug, but can't recall the details of the recreating
>
> > the bug off hand. I'd have to look up what stuff I was doing around March
>
> > this year. The r14805 commit message was "Fixed resize dimensions of X11
>
> > window".
>
> >
>
> > At a guess, perhaps we can just do this check when we suspect a resize.
>
> That is what I expect too. If this is required at all. Sadly I do not know
> exactly what
>
> type of event is guaranteed to arrive.
>
>
>
> > What are the event times you are seeing? What platform are you testing
> on?
>
> Fedora 22 x86_64. I now looked up the implementation in libX11 and it
> seems to
>
> introduce 3 round trips in total to the X server. That results in
> 0.6ms-0.8ms
>
> down to <= 0.2ms using the event visitor that just gets switched off
> completely
>
> by setting it to no traversal mode. That does not sound too much time, but
> if you
>
> want to squeeze the last out of your application you do not want to have a
>
> single round trip if it is not needed.
>
>
>
> Also, if you think about the 80Hz frame rate with an oculus for example,
> this
>
> round trip time difference of about 0.5ms turns already in
> 0.0005/(1/80)=0.04
>
> that is 4% reduced available cull time (or draw time) to hit the target
> frame
>
> rate - without having drawn a single pixel. And having a round trip here
> makes
>
> you much more prone to scheduling decisions in the system as the X server
> needs
>
> to be started up to to answer your request which makes these times much
> more
>
> jittery and increases the probability of a missed frame.
>
>
>
> Greetings
>
>
>
> Mathias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151103/8e013604/attachment-0003.htm>