We only do one SendBeginMainFrame per vsync - see |send_begin_main_frame_funnel_| in SchedulerStateMachine. Also WillSendBeginMainFrame is called just before calling SendBeginMainFrame. Also the LATE deadline is used when there's nothing to draw and we're waiting for a commit - as soon as there's something to draw we reschedule the deadline to IMMEDIATE or REGULAR based on the presence of touch handlers in the page.

Yes, but I did see it cause a BeginMainFrame when nothing changes, roughly IIRC:

- SetNeedsCommit()
- needs_begin_main_frame = true
- WillSendBeginMainFrame()
- needs_begin_main_frame == false
- SetNeedsAnimate()
- needs_begin_main_frame = true
- BeginMainFrame, Commit, Draw
- VSync, BeginFrame
- ->BeginMainFrame although nothing changed

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6414a4526b77dd087581d8a9c1cec50affc66333

commit 6414a4526b77dd087581d8a9c1cec50affc66333
Author: sievers <sievers@chromium.org>
Date: Fri Apr 22 21:33:20 2016

Android: Browser-side scheduling latency tweaks

    - Emit an immediate 'missed' BeginFrame when an
      BFObserver is added instead of waiting for next vsync
    - Remove unneeded requestRender() (=SetNeedsAnimate()) call

    The former helps both the browser compositor and display
    scheduler (now that it uses the same BeginFrameSource).

    Regarding the browser compositor:
    When the omnibox is hiding (or selection handles are showing)
    we need to browser composite with the correct scroll offset
    for a given renderer frame.

    Without this patch we run:
    ScrollBegin VSync SwapCompositorFrame VSync BrowserComposite

    Now we do:
    ScrollBegin VSync SwapCF MissedBF BrowserComposite VSync

    In the next interval, this works because if nothing changed yet,
    the scheduler will defer the BeginMainFrame until there is
    another change in the browser compositor tree (MODE_LATE).

    Calling SetNeedsAnimate()) from CompositorViewHolder when the
    top control offset changes is unnecessary, since this is a
    renderer-driven animation (causes an invalidation in the browser
    compositor tree), so will already cause the necessary
    UpdateLayerTreeHost(). Requesting SetNeedsAnimate()
    causes an extra BeginMainFrame() (SingleThreadProxy+scheduler
    are not particularly good at tracking these between needs_commit
    and needs_animate) and puts us into high latency mode otherwise.
    Fileed bug  crbug.com/602489  to make this more robust in
    SingleThreadProxy and scheduler.

TBR=dtrainor@chromium.org
BUG= 591725 , 602489 , 602485 , 604007 

Review URL: https://codereview.chromium.org/1879833002

Cr-Commit-Position: refs/heads/master@{#389248}

[modify] https://crrev.com/6414a4526b77dd087581d8a9c1cec50affc66333/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java
[modify] https://crrev.com/6414a4526b77dd087581d8a9c1cec50affc66333/content/browser/renderer_host/compositor_impl_android.cc