Here's a recording of the issue and a screenshot of what the flash looks like.
Note that the bottom of the video is showing up at the top of the screen

Deleted: fslp flash.mov 15.6 MB

fslp flash.mov 15.6 MB Download

Deleted: Screen Shot 2016-11-21 at 4.45.13 PM.png 366 KB

	Screen Shot 2016-11-21 at 4.45.13 PM.png 366 KB View Download

Make sure that this still actually hits the low power mode -- IIRC you need to have already setStyleMask before calling orderWindow.

You can check this with QuartzDebug (show detached regions) and also with the usual power monitoring tools.

several thoughts: 

1) Right now, both the fullscreen window and cocoa window have animationBehavior != setAnimationBehavior:NSWindowAnimationBehaviorNone

2) Have we tried fiddling with the setIsVisible: method on NSWindow rather than changing Window ordering?

More thoughts:

3) There's this nifty userDefault for NSAutomaticWindowAnimationsEnabled. Perhaps we should try fiddling with it. 

4) 
-[NSWindow orderWindow:relativeTo:]: calls
-[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] which looks complex, and has many references to animations. I haven't dug through the function in detail, but if __NSAutomaticWindowAnimationsEnabled returns false, all the logic should be short circuited and this should call
_doOrderWindowWithoutAnimation:relativeTo:findKey:forCounter:force:isModal:

I've been testing these flags out locally. Observation: This has nothing to do with window animations. [at least, in my tests. For this particular video, I was using setIsVisible to make the FSLP window visible/not [FSLP window is always in front]

Chrome Window: Video on black background.
FSLP window: video on blue background.

Notice that in the partial-frame, the background is blue! [so we're only seeing the FSLP window]. Furthermore, notice that the fence is diagonal. The frames both before and after the flash have a straight background fence. This means that we're actually seeing an out-dated frame from earlier in the video.

Deleted: fullscreen3_480p.mov 5.6 MB

fullscreen3_480p.mov 5.6 MB Download

This next video shows 2 frames [in quicktime] where a single updated frame is being shown by the FSLP window.

Deleted: fullscreen4_480p.mov 5.1 MB

fullscreen4_480p.mov 5.1 MB Download

And this next video shows the very obvious time-travel frame. Watch the text at the bottom and notice that flash from game 2 to game 1.

Deleted: fullscreen5_480p.mov 7.8 MB

fullscreen5_480p.mov 7.8 MB Download

My belief is becoming that the WindowServer plays fast and loose with synchronization of separate windows. And also probably doesn't update windows that are in the background. This seems to have gotten much worse in 10.12.

Horrible hack ideas:
1: make the FSLP window "just barely visible" (can we make the non-FSLP window ever-so-slightly translucent?)

2. make the FSLP window just draw the non-FSLP content on top but still in the FSLP window, when the content isn't FSLP-capable (e.g, has subtitles)

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

commit ec1c7cbfff53d770a16d007de3c665a41c035181
Author: erikchen <erikchen@chromium.org>
Date: Tue Nov 29 00:44:10 2016

mac: Don't allow animations on FullscreenLowPowerWindow.

The window is supposed to instantly pop behind and in front of the main browser
window.

BUG=667511

Review-Url: https://codereview.chromium.org/2532233002
Cr-Commit-Position: refs/heads/master@{#434800}

[modify] https://crrev.com/ec1c7cbfff53d770a16d007de3c665a41c035181/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.mm

Document that describes glitches when entering low power full screen: https://docs.google.com/document/d/1gGiahesea1yY67ZYoTDS06079-MSU_sbP3Q5ueVpd1U/edit#

Observation: For the partial frame flash, the offset is determined by the initial frame of the Window [which is currently 256]. In the attached video, I changed the initial size to be 768.

Deleted: fullscreen6_480p.mov 4.1 MB

fullscreen6_480p.mov 4.1 MB Download

This CL seems to have solved the bulk of the problem for me:
https://codereview.chromium.org/2539863002/#

I still see a time-traveling frame every 10 (20?) or so times I enter FSLP for the first time, but otherwise the transition is smooth.

Just tested the CL and it's significantly better

Deleted: lpfs.mov 19.0 MB

lpfs.mov 19.0 MB Download

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

commit e3f1197b3132ba4ad7192dfb13591a7bc19afd74
Author: erikchen <erikchen@chromium.org>
Date: Tue Nov 29 19:54:43 2016

Fix partial-screen flashes when first entering low power full screen.

NSWindow resizing is slow, so try to guess the right size when first creating
the window. Furthermore, resizing the window will create implicit animations for
the Window's views and layers. Disable those implicit animations.

BUG=667511

Review-Url: https://codereview.chromium.org/2539863002
Cr-Commit-Position: refs/heads/master@{#435062}

[modify] https://crrev.com/e3f1197b3132ba4ad7192dfb13591a7bc19afd74/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.mm