New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 659598 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Cleanup ui::Layer::SetShowSurface

Project Member Reported by fsam...@chromium.org, Oct 26 2016

Issue description

ui::Layer::SetShowSurface is a bit clunky in that it requires a lot of parameters and callbacks. The Require and Satisfy callbacks look like they're all usually the same (and they're all going to change with Surface references anyway). Maybe it might make sense to instead take in a "SurfaceInfo" object that contains a bundle of these things and methods that can be called to add and remove references. There could be a Mojo implementation that does IPC and a local implementation that does a method call.


 
Owner: samans@chromium.org
Status: Assigned (was: Untriaged)
class SurfaceInfo {
 public:
   virtual void AddReference() = 0;
   virtual void RemoveReference() = 0;
   
   const SurfaceId& surface_id() const { return surface_id_; }
   const gfx::Size& frame_size() const { return frame_size_; }
   float device_scale_factor() const { return device_scale_factor_; }

 private:
   SurfaceId surface_id_;
   gfx::Size frame_size_;
   float device_scale_factor_ = 1.f;
};

SurfaceLayer has a std::unique_ptr<SurfaceInfo> that it replaces on SetSurfaceId.
Clients that use SurfaceInfo should not know about SurfaceSequence.
Cc: kylec...@chromium.org piman@chromium.org
Note that this also involves cc::SurfaceLayer and not just ui::Layer.

Part of the goal here is to reduce the usage of SurfaceSequence in the code base so that we can transition to kylechar's surface references easily and smoothly.

+kylechar@, +piman@
It would also be nice if SurfaceInfo can be sent over mojo IPC. That way, the window server can send the embedder a SurfaceInfo for the child, and the embedder can simply: layer_->SetSurfaceInfo(std::move(surface_info)) and the right thing will happen: the surface will magically appear.

References will not be immediately added or removed, and are instead tied to a WindowCompositorFrameSink. Thus we can add a method WindowCompositorFrameSink::AddChildSurface(SurfaceInfo).

Mus versions of SurfaceInfo::AddReference / RemoveReference will just update some internal book-keeping and populate the CompositorFrame in WindowCompositorFrameSink::SubmitCompositorFrame.


An interesting thought: Maybe "RemoveReference" isn't a necessary API. Maybe it can happen implicitly when a SurfaceInfo object is deleted. SurfaceInfo could instead have observers that are tied to it. SurfaceLayer owns SurfaceInfo, and WindowCompositorFrameSink is simply a SurfaceInfoObserver.

WindowCompositorFrameSink::AddSurfaceReference(SurfaceInfo* surface);

WindowCompositorFrameSink is informed when SurfaceInfo goes away.
For current Chrome IPC code, we don't have to worry about transmitting SurfaceInfo over IPC. Today, SurfaceInfo can take in a LayerTreeHost on construction, and can call into that to generate a SurfaceSequence for the embedder inside AddReference.
Even better, maybe constructing the SurfaceInfo adds the reference in the Chrome IPC case.

Comment 9 by samans@chromium.org, Nov 29 2016

Status: Started (was: Assigned)
Blocking: 601863
Components: MUS
Labels: Proj-Mustash-Mus-GPU displaycompositor
Project Member

Comment 11 by bugdroid1@chromium.org, Dec 16 2016

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

commit e7345c8c5ec3831fb46788c903ea62b67a7a4174
Author: samans <samans@chromium.org>
Date: Fri Dec 16 02:51:16 2016

Splitting DidSwap in cc::SwapPromise to WillSwap and DidSwap

Currently DidSwap runs before the swap, but we need a method
that is run after it. DidSwap is also not the best name because
it's called before the swap is done, so we believe WillSwap will
be a better name for it. So DidSwap will be renamed to WillSwap
and we will create a new DidSwap method that is run after the swap.

BUG= 659598 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/blimp/client/core/compositor/blimp_compositor.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/layers/surface_layer.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/output/latency_info_swap_promise.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/output/latency_info_swap_promise.h
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/output/swap_promise.h
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/layer_tree_impl.h
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/layer_tree_impl_unittest.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/cc/trees/swap_promise_manager_unittest.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/content/renderer/gpu/queue_message_swap_promise.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/content/renderer/gpu/queue_message_swap_promise.h
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/content/renderer/gpu/queue_message_swap_promise_unittest.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/content/renderer/render_view_impl.cc
[modify] https://crrev.com/e7345c8c5ec3831fb46788c903ea62b67a7a4174/content/test/layouttest_support.cc

Project Member

Comment 12 by bugdroid1@chromium.org, Dec 16 2016

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

commit d0de6cf72a25d789a507d6eb904a8f1ae314d00b
Author: samans <samans@chromium.org>
Date: Fri Dec 16 06:15:48 2016

Getting rid of CompositorFrameMetadata::satisfies_sequences

This CL helps unify the way we destroy references to surfaces.
We currently have two code paths for satisfying a surface sequence.
One is through calling the satisfy callback which is given to the
reference holder, and the other one is through populating
satisfies_sequences in CompositorFrameMetadata and letting
Surface::QueueFrame do the rest of the work. Eventually they both do
the same thing: they call SurfaceManager::DidSatisfySequences. This CL
gets rid of satisfies_sequences in CompositorFrameMetadata and from now
on the only way for satisfying a sequence is through the callback. This
is a necessary change because we are phasing out SurfaceSequence and
exposing it in CompositorFrameMetadata is not a good idea.

BUG= 659598 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/blimp/client/core/compositor/blimp_compositor.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/ipc/compositor_frame_metadata.mojom
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/ipc/compositor_frame_metadata_struct_traits.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/ipc/compositor_frame_metadata_struct_traits.h
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/layers/surface_layer.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/output/compositor_frame_metadata.h
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/surfaces/surface.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/surfaces/surface_factory_unittest.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/surfaces/surface_manager.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/cc/surfaces/surface_manager.h
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b/ui/android/delegated_frame_host_android.cc

Project Member

Comment 13 by bugdroid1@chromium.org, Dec 16 2016

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

commit f0983129357f6a46b29756ed183115b8dc8e371e
Author: ksakamoto <ksakamoto@chromium.org>
Date: Fri Dec 16 06:55:11 2016

Revert of Getting rid of CompositorFrameMetadata::satisfies_sequences (patchset #17 id:380001 of https://codereview.chromium.org/2537943002/ )

Reason for revert:
Suspected cause of ChromiumOS compile failure.
https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Builder%20%28dbg%29/builds/81640

Original issue's description:
> Getting rid of CompositorFrameMetadata::satisfies_sequences
>
> This CL helps unify the way we destroy references to surfaces.
> We currently have two code paths for satisfying a surface sequence.
> One is through calling the satisfy callback which is given to the
> reference holder, and the other one is through populating
> satisfies_sequences in CompositorFrameMetadata and letting
> Surface::QueueFrame do the rest of the work. Eventually they both do
> the same thing: they call SurfaceManager::DidSatisfySequences. This CL
> gets rid of satisfies_sequences in CompositorFrameMetadata and from now
> on the only way for satisfying a sequence is through the callback. This
> is a necessary change because we are phasing out SurfaceSequence and
> exposing it in CompositorFrameMetadata is not a good idea.
>
> BUG= 659598 
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
>
> Committed: https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b
> Cr-Commit-Position: refs/heads/master@{#439043}

TBR=fsamuel@chromium.org,danakj@chromium.org,dcheng@chromium.org,jbauman@chromium.org,dtrainor@chromium.org,jam@chromium.org,samans@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 659598 

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

[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/blimp/client/core/compositor/blimp_compositor.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/ipc/compositor_frame_metadata.mojom
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/ipc/compositor_frame_metadata_struct_traits.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/ipc/compositor_frame_metadata_struct_traits.h
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/layers/surface_layer.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/output/compositor_frame_metadata.h
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/surfaces/surface.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/surfaces/surface_factory_unittest.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/surfaces/surface_manager.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/cc/surfaces/surface_manager.h
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e/ui/android/delegated_frame_host_android.cc

Project Member

Comment 14 by bugdroid1@chromium.org, Dec 16 2016

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

commit 73809d9eebbab0d932cb78ff3618b55a5570cfaf
Author: ksakamoto <ksakamoto@chromium.org>
Date: Fri Dec 16 08:02:58 2016

Reland of Getting rid of CompositorFrameMetadata::satisfies_sequences (patchset #1 id:1 of https://codereview.chromium.org/2585543003/ )

Reason for revert:
Relanding this. The real culprit was https://codereview.chromium.org/2578893003/.

Original issue's description:
> Revert of Getting rid of CompositorFrameMetadata::satisfies_sequences (patchset #17 id:380001 of https://codereview.chromium.org/2537943002/ )
>
> Reason for revert:
> Suspected cause of ChromiumOS compile failure.
> https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Builder%20%28dbg%29/builds/81640
>
> Original issue's description:
> > Getting rid of CompositorFrameMetadata::satisfies_sequences
> >
> > This CL helps unify the way we destroy references to surfaces.
> > We currently have two code paths for satisfying a surface sequence.
> > One is through calling the satisfy callback which is given to the
> > reference holder, and the other one is through populating
> > satisfies_sequences in CompositorFrameMetadata and letting
> > Surface::QueueFrame do the rest of the work. Eventually they both do
> > the same thing: they call SurfaceManager::DidSatisfySequences. This CL
> > gets rid of satisfies_sequences in CompositorFrameMetadata and from now
> > on the only way for satisfying a sequence is through the callback. This
> > is a necessary change because we are phasing out SurfaceSequence and
> > exposing it in CompositorFrameMetadata is not a good idea.
> >
> > BUG= 659598 
> > CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
> >
> > Committed: https://crrev.com/d0de6cf72a25d789a507d6eb904a8f1ae314d00b
> > Cr-Commit-Position: refs/heads/master@{#439043}
>
> TBR=fsamuel@chromium.org,danakj@chromium.org,dcheng@chromium.org,jbauman@chromium.org,dtrainor@chromium.org,jam@chromium.org,samans@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 659598 
>
> Committed: https://crrev.com/f0983129357f6a46b29756ed183115b8dc8e371e
> Cr-Commit-Position: refs/heads/master@{#439051}

TBR=fsamuel@chromium.org,danakj@chromium.org,dcheng@chromium.org,jbauman@chromium.org,dtrainor@chromium.org,jam@chromium.org,samans@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 659598 

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

[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/blimp/client/core/compositor/blimp_compositor.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/ipc/compositor_frame_metadata.mojom
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/ipc/compositor_frame_metadata_struct_traits.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/ipc/compositor_frame_metadata_struct_traits.h
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/layers/surface_layer.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/output/compositor_frame_metadata.h
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/surfaces/surface.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/surfaces/surface_factory_unittest.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/surfaces/surface_manager.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/cc/surfaces/surface_manager.h
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/73809d9eebbab0d932cb78ff3618b55a5570cfaf/ui/android/delegated_frame_host_android.cc

Project Member

Comment 15 by bugdroid1@chromium.org, Dec 17 2016

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

commit 72b2a28cb2ffa0dabe4505e14ba65c41c20495c5
Author: samans <samans@chromium.org>
Date: Sat Dec 17 02:44:15 2016

Introducing SurfaceReferenceFactory

This CL introduces SurfaceReferenceFactory which can create surface references
while hiding the implementation details from its client. So the client cannot tell if the
underlying implementation is SurfaceSequence or SurfaceReference, which paves the
way for replacing SurfaceSequence with SurfaceReference. All require / satisfy
callbacks are now gone and are replaced with different implementations of
SurfaceReferenceFactory.

This CL also adds SurfaceInfo, which contains information
about an embedded surface that are usually passed around together.

BUG= 659598 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/blimp/client/core/compositor/blimp_compositor.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer_impl.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer_impl.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer_impl_unittest.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/BUILD.gn
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/direct_surface_reference_factory.cc
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/direct_surface_reference_factory.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/sequence_surface_reference.cc
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/sequence_surface_reference.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/sequence_surface_reference_factory.cc
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/sequence_surface_reference_factory.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_info.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_manager.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_manager.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_reference_base.cc
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_reference_base.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_reference_factory.h
[add] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/surfaces/surface_reference_owner.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/trees/layer_tree_host.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/components/exo/surface.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/components/exo/surface.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/content/browser/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/content/renderer/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/content/renderer/child_frame_compositing_helper.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/content/renderer/child_frame_compositing_helper.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/third_party/WebKit/Source/platform/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/third_party/WebKit/Source/platform/graphics/CanvasSurfaceLayerBridge.cpp
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/third_party/WebKit/Source/platform/graphics/CanvasSurfaceLayerBridge.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/android/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/android/delegated_frame_host_android.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/compositor/BUILD.gn
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/compositor/layer.cc
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/compositor/layer.h
[modify] https://crrev.com/72b2a28cb2ffa0dabe4505e14ba65c41c20495c5/ui/compositor/layer_unittest.cc

Status: Fixed (was: Started)
Blocking: -601863
Components: -MUS Internals>Services>WindowService

Sign in to add a comment