This is related to  issue 736826 .

While there is a separate fix for External BFS I think there is an underlying issue that allow BeginFrame to be generated with only a few micro-second difference between the begin_frame_us timestamp.

I think this happens only in Browser process and only when DirectLayerTreeFrameSink is used.

I cannot come up with exact repro steps yet, but I know the following facts.

1) SetTimebaseAndInterval is based on v-sync parameters that are generated in GPU process on every frame. It takes time for updated v-sync parameters to reach DelayBasedTimeSource in the browser time so in some rare cases the timebase may be a few frames behind.

2) timebase is reported by the driver and may have some jitter. So when SetTimebaseAndInterval is arrived and next_tick_time_ is calculated it might end up just a little bit ahead (a few microseconds) compared to the current time.

3) That would result in generating a next tick in rapid succession with the previous one.

4) Normally there is a code in DelayBasedBFS that should prevent propagating a BeginFrame which is less than half interval after the previous one. But that depends on LastUsedBeginFrameArgs() from each observer and I think in case of DirectLayerTreeFrameSink (which is an observer itself), it might be recreated in some cases.

Anyway, having the following workaround in DelayBasedBFS seems to be wrong:

    BeginFrameArgs last_args = obs->LastUsedBeginFrameArgs();
    if (!last_args.IsValid() ||
        (current_begin_frame_args_.frame_time >
         last_args.frame_time +
             current_begin_frame_args_.interval / kDoubleTickDivisor)) {
      obs->OnBeginFrame(current_begin_frame_args_);
    }

I think instead there should be a logic in DelayBasedTimeSource that should guarantee that it wouldn't generate a tick too close to a previous one when SetTimebaseAndInterval shifts the timebase one way or another. In other words DelayBasedTimeSource should ensure continuity and smoothness of its ticks.