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

ui/views/cocoa/bridged_native_widget.mm

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import "ui/views/cocoa/bridged_native_widget.h"
 
 #import <objc/runtime.h>
 #include <stddef.h>
 #include <stdint.h>
 
@@ skipping 823 matching lines @@
   // asynchronous (and things like deminiaturize in AppKit are not), it can
   // result in a CALayer appearing on screen before it has been redrawn in the
   // GPU process. This is a general problem. In content, a helper class,
   // RenderWidgetResizeHelper, blocks the UI thread in -[NSView setFrameSize:]
   // and RenderWidgetHostView::Show() until a frame is ready.
   if (layer()) {
     layer()->SetVisible(window_visible_);
     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(
       window_visible_);
 
   // Toolkit-views suppresses redraws while not visible. To prevent Cocoa asking
   // for an "empty" draw, disable auto-display while hidden. For example, this
   // prevents Cocoa drawing just *after* a minimize, resulting in a blank window
   // represented in the deminiaturize animation.
   [window_ setAutodisplay:window_visible_];
@@ skipping 530 matching lines @@
   [bridged_view_ setMouseDownCanMoveWindow:draggable];
   // AppKit will not update its cache of mouseDownCanMoveWindow unless something
   // changes. Previously we tried adding an NSView and removing it, but for some
   // reason it required reposting the mouse-down event, and didn't always work.
   // Calling the below seems to be an effective solution.
   [window_ setMovableByWindowBackground:NO];
   [window_ setMovableByWindowBackground:YES];
 }
 
 }  // namespace views