MacViews: Trigger shadow invalidation when a translucent window is shown.

ui/views/cocoa/bridged_native_widget.mm

Index: ui/views/cocoa/bridged_native_widget.mm
diff --git a/ui/views/cocoa/bridged_native_widget.mm b/ui/views/cocoa/bridged_native_widget.mm
index d4e0125716d49df204a2ff73a0446574c4832144..1e52938b0105af2cc27eca687a4f0351a327c918 100644
--- a/ui/views/cocoa/bridged_native_widget.mm
+++ b/ui/views/cocoa/bridged_native_widget.mm
@@ -841,6 +841,11 @@ NSComparisonResult SubviewSorter(NSViewComparatorValue lhs,
     layer()->SchedulePaint(gfx::Rect(GetClientAreaSize()));
   }
 
+  // For translucent windows which are made visible, recalculate shadow when the

[tapted, 2016/09/15 04:12:26]

this probably belongs in the if (layer()) block above; with the associated
comment. -- (i.e. if layer() is false, there is no compositor for a frame to
come from. But, more importantly, we might later investigate whether we should
not tie the window visibility to layer visibility, and instead rely on occlusion
APIs and keep the layer always "visible", in which case there won't be a repaint
triggered here and hence no point waiting for a frame swap that may never
happen.)

And support for widgets not backed by layers actually got removed after the
block of code above was written, so layer() should only be false during
teardown.

[karandeepb, 2016/09/15 06:30:10]

Done. I probably need to do this for the initial_visibility_suppressed_ flag
that I added for the "flash of grey" bug as well.
Why is the window and layer visibility tied up currently though? Does It save
memory/suppresses frame generation when the window is not visible? Also how
would relying on occlusion state help here? 
I guess we should still keep the if checks since it's probably safer as some of
these codepaths can be entered during teardown?

[tapted, 2016/09/15 06:37:41]

The most concrete answer is that there are tests that ensure that it is tied
together :). i.e. without the goo above, tests will fail, but it might not be
the necessary for those tests to pass on Mac. Needs some investigation.

the occlusion APIs helps with performance, e.g., by turning off animations or
increasing timer intervals -- WebContents uses them on Mac for "things".
Occlusion on Mac could help us properly support the same rationale that window
visibility is used for on other platforms, since window visibility is tricky to
pin down on Mac. 
Yeah I think so (of course setting a bool is "safe" whereas dereferencing null
is not, but conceptually these should be treated the same.

+  // frame from the compositor arrives.
+  if (![window_ isOpaque])
+    invalidate_shadow_on_frame_swap_ = window_visible_;
+
   NotifyVisibilityChangeDown();
 
   native_widget_mac_->GetWidget()->OnNativeWidgetVisibilityChanged(