animationFrameScheduler - Execution not syncing with requestAnimationFrame

[Achilles1515]

Bug Report

See this StackBlitz example, where I am testing different methods of using animationFrameScheduler to (hopefully) execute code on every requestAnimationFrame.

The following methods are as follows:

/** REAL */
requestAnimationFrame(raf);
function raf() {
  real++;
  requestAnimationFrame(raf)
}
/////////////

/** FIRST */
of(0, animationFrameScheduler)
  .pipe(repeat())
  .subscribe(() => {
    first++;
  });

/** SECOND */
interval(0, animationFrameScheduler)
  .subscribe(() => {
    second++;
  });

/** THIRD */
scheduled(of(0), animationFrameScheduler)
  .pipe(repeat())
  .subscribe(() => {
    third++;
  });

/** FOURTH */
animationFrameScheduler.schedule(function() {
  fourth++;
  this.schedule();
}, 0, 0);

When running these all at the same time, the console log outputs of the counters after 1 second are as follows:

REAL:	59
FIRST:	36
SECOND:	71
THIRD:	35
FOURTH:	70

Why do these not all match the "real" value of 59?

Next, comment out the first method. Console output:

REAL:	60
FIRST:	0
SECOND:	80
THIRD:	40
FOURTH:	80

Why do the second, third, and fourth outputs here not "match" the above run?

Next, comment out the first, second, and third methods. Console output:

REAL:	60
FIRST:	0
SECOND:	0
THIRD:	0
FOURTH:	118

(this fourth method is a copy of the animationFrameScheduler example from the official docs)

Why is this running almost twice as often as requestAnimationFrame? Probably related to #4972

In general with all these "comment out" examples, why is the number of schedules running affecting these execution counts?

Environment

• Runtime: Chrome 80
• RxJS version: 6.5.5

[cartant]

The fundamental problem is that the animationFrameScheduler is not a loop - like the REAL example in your StackBlitz - rather, the scheduler queues the scheduled actions and ensures that they run on an animation-frame boundaries, so to speak.

Evidently, there is some overhead in the scheduler implementation. AFAICT, a significant amount of this overhead is due to the bug raised in #4972 is also seen here - as you've mentioned - and I have some idea about what might causing it.

However, for loops like the one in the REAL example, the (relatively) new animationFrames observable should be used. (Be aware, however, that there is an open issue to bring that observable's emitted times into line with the requestAnimationFrame API - see #5194.)

[Achilles1515]

Thanks for the comment. This is good info to know.
I'll close this issue for now.

[cartant]

FWIW, most (almost all?) of the overhead would have been effected by the other bug you referenced - which was fixed in 33c9c8c. But you would still be better off using animationFrames for a loop.

[Achilles1515]

But you would still be better off using animationFrames for a loop.

I noticed that "double execution" bug in the Angular CDK drag-drop project in the code handling auto-scrolling during a drag.

https://github.com/angular/components/blob/master/src/cdk/drag-drop/drop-list-ref.ts#L778

Looks like they are referencing RxJS 6.5.3 with that project (so can't use animationFrames). I was planning on putting in a PR to switch to a "regular" requestAnimationFrame loop instead.