Today we trigger rAF/BeginMainFrame right after it's requested if there wasn't one already in the current frame, and we also generate a "missed" begin frame if we were not active then. This can put us into a inconsistent and unpredictable rendering schedule as subsequent rAFs can also trigger in the middle of a frame. So we might never see the expected behavior of rAF being closely aligned to vsync until we go idle again.

AFAICT there are two motivations for the above behavior:

1. Reducing latency for timer driven content since those can ask for BeginMainFrame in the middle of a frame. altimin@ told me that this shouldn't be a priority

2. On Android, we ask for a begin frame on receiving input. But by the time the renderer receives input, the browser has already seen begin frame. The browser sends the begin frame speculatively, and renderer's BeginFrameSource caches the begin frame. When the renderer scheduler asks for begin frames (by calling AddObserver), it gets the cached begin frame as a "missed" begin frame.

  All of this convoluted logic is because the renderer BFS doesn't know about the scheduler until AddObserver is called. However, the interface between renderer and browser, CompositorFrameSink, doesn't have this restriction, so the browser can send begin frames as it pleases (and it does in the above case). We can get rid of the BFS in the renderer so that BeginFrame goes from ClientLTFS -> LTHI -> Proxy -> Scheduler directly (modulo disable vsync case), and SetNeedsBeginFrame goes the other way, and there's no AddObserver/RemoveObserver non-sense. The scheduler is the only observer of the renderer BFS. The other producers e.g. video, canvas, etc. receive begin frames from their CFS.

There are two basic tasks:
1. Get rid of missed begin frame logic and ensure speculative begin frame on Android still works.
2. Modify scheduler logic to restrict BeginMainFrame to begin frame time.

Doing this will also put us on the path of calling PrepareTiles/PerformImplSideInvalidation at the beginning of a frame when there's no commit/rAF pending, and waiting for active tree tiles (NotifyReadyToDraw) to reduce checkerboarding. And the scheduling is simpler and predictable.

I have a rough plan of changes we need to make in cc scheduler to achieve this. But I need to write up something for further discussion.