CC: → karlt@mozbugz.karlt.net
Flags: needinfo?(bbirtles@mozilla. com) →
Brian Birtles (:birtles, busy 22~30 Aug)
said:
(In reply to Markus Stange [:mstange] from comment #49)
> Brian, can you look into this some more? It sounds like the drift detection
> from your patch isn't good enough, or some other noise is introduced into
> the timestamps. At least that's what I'm concluding from the fact that
> jastekken reports that the current state is worse than with my first try
> build (with the patch in comment 32).
I'm afraid it's going to be difficult for me to have a proper look at this, at
least during Q3. I'm not really sure how APZ is using timestamps so it's hard
to guess how the native UI event time to TimeStamp code might be affecting
this. Karl may have a better idea.
The next step might be to add some debugging output to
widget/SystemTimeConverter.h to indicate when we adjust for forwards skew and
backwards skew and see if they correspond with the jumps. Also, we might see if
there is an async method for getting the current time on windows like we use on
Linux.
Karl Tomlinson (ni?:karlt)
said:
The lack of a winnt GetTimeAsyncForPossibleBackwardsSkew() implementation
means that skew correction is implemented in one direction only.
However, the report of correction of cumulative delay sounds like it happens
to be the direction that helps.
If the skew in this direction is large then the result is essentially that
event timestamps represent times of processing the events instead of
hardware (or OS) event times. However, the skew rates reported here don't
sound so large that I would guess that effect. I suspect something else might
be involved.