Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/34f22b83b76ac457f93d35aece3ed56657689d7d..7bea53f048244f5d6d117c5484733130d3248009?pretty=fuller&n=100

Suspecting: r380670 ?

Please help to reassign if your change is not the cause for this issue.

Adding release block label, please undo if not the case. Not seeing this on Linux OS as well.

Can you grab a more narrow bisect? Thanks.

With response to comment #4,
There are no MAC builds available in between 51.0.2673.0 and 51.0.2678.0 and Issue is specific to MAC OS. 
After performing manual bisect, got the same range as mentioned in comment #1.

I don't understand what you mean when you say "There are no MAC builds available in between 51.0.2673.0 and 51.0.2678.0". At the very least, there will be a canary build for 2674, 2675, etc.

An actual bisect should give much more narrow results. If the builds for that are missing, we should figure out why.

Just to update the latest behavior, Issue is able to repro on Mac OS 10.11.4 using chrome latest canary M51-51.0.2692.0.

With response to comment #8,
There is no Signed official builds for MAC between version 51.0.2673.0 and 51.0.2678.0 .
Performed manual regression and in manual bisect,got revision no-380668 as good and revision no-380677 as bad.

This is a Mac specific issue and below is bisect URL
Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/34f22b83b76ac457f93d35aece3ed56657689d7d..7bea53f048244f5d6d117c5484733130d3248009?pretty=fuller&n=100

Thanks! Will look into this.

Just to update, issue is still seen on Canary version 51.0.2695.1 on MAC 10.11.4

Issue still reproduced on Mac 10.11.3 using canary 51.0.2699.0.
erikchen@ : Could you please take a look into this.

Just to update, issue is still seen on Canary version 52.0.2713.0 on MAC 10.11.4. Issue is marked with a blocker label, request to please take a look into it.

Issue still reproduced on Mac 10.11.4 using canary 52.0.2717.0.
erikchen@ : Could you please take a look into this and update further.

Can you provide machine specifications? I tried this on two different machines, and couldn't reproduce the regression.

A went around trying this on different machines and finally found one (MacBookAir, NVidia GeForce 320M) that had this problem. I took traces on the problematic machine, and a good machine.

On the problematic machine, ImageTransportSurfaceOverlayMac::glFinish has a wall duration of 13ms+. 

I tried taking a trace on another machine with an NVidia GPU (GeForce GT 750M 2048 MB). 1ms wall duraiton.
Same machine iGPU, 0.014ms wall duration.

This is pretty worrisome.

Deleted: trace_easter_egg_game_fast.json.gz 3.1 MB

trace_easter_egg_game_fast.json.gz 3.1 MB Download

Deleted: trace_easter_egg_game_slow.json.gz 9.0 MB

trace_easter_egg_game_slow.json.gz 9.0 MB Download

If we --disable-mac-overlays, does that affect the glFinish time?

Okay, there are two bugs, both of which I can only reproduce on this MacBookAir.

1. Dropped frames: [presumably due to glFinish wall duration >= 13ms]

Neither --disable-2d-canvas-image-chromium nor --disable-mac-overlays affects the wall duration. For all three cases (no flags, or either of the above flags), the FPS stays at 60, and drops to around ~50-55 sometimes.

2. Time traveling frames.
If you step through Actual Video from post #0 frame by frame, and only look at the score in the top right hand corner, you'll see that occasionally, the game goes "backwards" by a frame. First one happens at score 20/21.

I've been able to reproduce this on the MacBookAir, but I've never been able to catch it on a screen recording.

It only reproduces on Chrome Beta (51.0.2704.29 ) with no additional flags.
I've never reproduced it with either --disable-mac-overlays or --disable-2d-canvas-image-chromium.

Furthermore, I don't think I've ever managed to reproduce this on Chrome Canary (52.0.2718.0), regardless of the flags that I pass on startup.

TEs: Can you please confirm whether this problem is still on the latest Canary? Please take screen recordings, and notice that there are two different problems:
(1) Skipped frames.
(2) Time traveling frames.

With response to comment #21

Above issue is still reproducible on latest canary version i.e 52.0.2719.0 

Please refer attached video 

Deleted: Actual_Result.mov 1.3 MB

Actual_Result.mov 1.3 MB Download

Please read this message before responding.

There are two different problems, as per Comment #21. Don't just say: "Above issue is still reproducible", since it doesn't indicate the type of problem.

I went through the video in #22, and saw skipped frames, but no time traveling frames. It is very important that we confirm that there are no time traveling frames on Canary.

Please try to reproduce time traveling frames on Canary.

ccameron@ and I looked into this. 

The root cause of the time traveling frames is that IOSurfaces are being reused by Canvas before they are finished being consumed by the Window Server. We can't create a syncpoint in the Window Server, so we will need to fix the timing at which GMB resources [IOSurfaces] get passed back to clients of cc::TextureLayer. Until then, we should probably turn off GMB re-use.

This problem isn't seen on Canary, probably because of the CL:
"Clean up ImageTransportSurfaceOverlayMac timing"
https://codereview.chromium.org/1867163002

That should probably be merged to M51 on a matter of principle.

With response to comment # 23:

Could you please help out in finding travelling frame difference,If possible with a screen cast.

Please see comment #20. 

"""
If you step through Actual Video from post #0 frame by frame, and only look at the score in the top right hand corner, you'll see that occasionally, the game goes "backwards" by a frame. First one happens at score 20/21.
"""

With response to comment # 23 & 26:
Rechecked again on latest canary i.e 52.0.2722.0 and found that the score on the top right hand corner goes "backwards" by a frame at Score 93/95,Will you please confirm

Please refer attached screencast

Deleted: Actual_Timeframe.mov 1.8 MB

Actual_Timeframe.mov 1.8 MB Download

I don't see any backwards frames in your video in #27. I think this verifies our theory that ccameron's changes from #24 more or less suppressed the problem to a point where it is no longer visible.

CL: https://codereview.chromium.org/1932393002/

Your change meets the bar and is auto-approved for M51 (branch: 2704)

Please merge your change to M51 branch 2704 by 5:00 PM PST Friday (05/06) so we can take it for next week beta release.Thank you.

Please merge your change to M51 branch 2704 by 5:00 PM PST Monday(05/09) so we can take it for next week beta release.Thank you.

https://codereview.chromium.org/1953293005/

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

[Auto-generated comment by a script] We noticed that this issue is targeted for M-51; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-51 label, otherwise remove Merge-TBD label. Thanks.

[Bulk edit]

Our blockerbot script was offline; it was recently brought back online, and thus labeled many old issues (including this one) erroneously.  Removing Merge-TBD label since all milestones for this issue are already completed; no further work should be done.