Software compositing fallback for Viz |
||||||||||||||||||||||||||
Issue descriptionThoughts doc about launching gpu process and platform things. https://docs.google.com/document/d/1nDAFy7Up_Qnxk7x39FBafJ-KuMWMVIFM9exdqYUdShQ/edit#heading=h.9ssjx7u4qc2k Starting a list of problems we'll need to think about. Can add to it (don't remove tho or we lose history). 1. Compositing mode reporting needs to be decided and reported in the gpu process, to the browser, and bounce to the renderers. 2. HostFrameSinkManager::CreateCompositorFrameSink explodes if the renderer falls back to software cuz it already has a CompositorFrameSink. We should pull that CFS out of the LayerTreeFrameSink and stuff it back into a new one instead of making one from scratch. 3. GpuDisplayProvider has no idea about software compositing, needs to be able to set up a software output surface, and decide to fall back on enough errors. 4. Because gpu process is restartable, if the browser sees it fall back to software it needs to tell the gpu process the next time around. 5. If gpu process is failing to launch, browser needs to tell it to stop trying to use gpu. Not sure how to combine this with (4) well, as that one comes from VizProcessFactory, and this one from GpuProcessHost. 6. Setting up the OutputSurface is platform specific (see doc) 7. Shared bitmap sequence numbers go to the browser in order to sync them with the compositor frame. Need to sync shared bitmap id generation with compositor frames to the viz process instead.
Showing comments 26 - 125
of 125
Older ›
,
Dec 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c commit d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c Author: danakj <danakj@chromium.org> Date: Fri Dec 01 22:10:37 2017 viz: force_software_compositing flag for CreateRootCompositorFrameSink For ui::Compositors that don't need to embed anything (eg. tooltips) they may be set to use software compositing even if the system as a whole is using gpu compositing. This adds the flag to CreateRootCompositorFrameSink plumbing, all the way through to the GpuDisplayProvider. In GpuDisplayProvider it adds code to create (for most platforms) a SoftwareOutputDevice. It renames DisplayOutputSurface to GLOutputSurface, and adds a SoftwareOutputSurface, which is created in the software compositing case. This now crashes if software compositing is forced, as the ui compositor has a null SharedBitmapManager. Once we set up the SharedBitmapManager in the viz and browser processes we should be able to get software compositing pixels. Lots of TODOs aded as appropriate. The auto-fallback on fatal error making a GL context is not implemented yet in GpuDisplayProvider. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I82855e03df1c156e1a0b1c4bbc4eb35ffb3deb51 Reviewed-on: https://chromium-review.googlesource.com/798153 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#521083} [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/common/gpu/in_process_context_provider.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/common/gpu/in_process_context_provider.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/host/host_frame_sink_manager.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/host/host_frame_sink_manager.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/host/host_frame_sink_manager_unittest.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/BUILD.gn [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/display_provider.h [rename] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gl_output_surface.cc [rename] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gl_output_surface.h [rename] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gl_output_surface_ozone.cc [rename] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gl_output_surface_ozone.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gpu_display_provider.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/gpu_display_provider.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_device_ozone.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_device_ozone.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_device_ozone_unittest.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_device_x11.cc [add] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_surface.cc [add] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/display_embedder/software_output_surface.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/frame_sinks/frame_sink_manager_impl.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/service/frame_sinks/frame_sink_manager_impl.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/components/viz/test/test_frame_sink_manager.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/content/browser/compositor/gpu_process_transport_factory.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/content/browser/compositor/viz_process_transport_factory.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/content/browser/compositor/viz_process_transport_factory.h [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/services/ui/ws/window_server.cc [modify] https://crrev.com/d92cc04210d91dbbfdb13ed7dbf74bc78f7e7a5c/services/viz/privileged/interfaces/compositing/frame_sink_manager.mojom
,
Dec 6 2017
When running --enable-viz on my Linux desktop, I'm encountering a crash that led me to this bug. I run my local chrome build (ToT), and whenever I hover over any UI buttons that animate, it causes a crash in two processes. The first is in the GPU process, where X11 claims "Most likely this is a multi-threaded client and XInitThreads has not been called." The second is in the browser process, because the SharedBitmapManager is null, and ResourceProvider::CreateBitmapResource() is dereferencing that null pointer. I tried digging into the root cause, and that's what brought me here. Seems there's a TODO in VizProcessTransportFactory::OnEstablishedGpuChannel(): https://cs.chromium.org/chromium/src/content/browser/compositor/viz_process_transport_factory.cc?rcl=8390d6521342c17eb17ec090e24641e74b995e28&l=435 So, is this just a hole in the implementation we haven't filled in yet, or have I discovered a separate bug? Crash from GPU process: [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. u/chromium/src/out/Release/chrome --type=gpu-process --field-trial-handle=16003999287186601889,1002294839360157693,131072 --disable-breakpad --enable-viz --log-level=1 --user-data-dir=/usr/local/google/home/miu/caches/debug-chrome --gpu-preferences=GAAAAAAAAAAAAQAAAQAAAAAAAAAAAGAA --gpu-vendor-id=0x10de --gpu-device-id=0x11b4 --gpu-driver-vendor=Nvidia --gpu-driver-version=367.57 --gpu-driver-date --user-data-dir=/usr/local/google/home/miu/caches/debug-chrome --log-level=1 --service-request-channel-token=11891335AACAD645C3C038916B202015: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Received signal 6 #0 0x7f605b4d028c base::debug::StackTrace::StackTrace() #1 0x7f605b4cfd61 base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7f605b622330 <unknown> #3 0x7f604e4f6c37 gsignal #4 0x7f604e4fa028 abort #5 0x7f604e4efbf6 <unknown> #6 0x7f604e4efca2 __assert_fail #7 0x7f6050d6779c <unknown> #8 0x7f6050d685c3 _XReply #9 0x7f6050d4fc74 _XGetWindowAttributes #10 0x7f6050d4fde1 XGetWindowAttributes #11 0x7f604d3aa44c viz::SoftwareOutputDeviceX11::SoftwareOutputDeviceX11() #12 0x7f604d373780 viz::GpuDisplayProvider::CreateDisplay() #13 0x7f604d37e63c viz::FrameSinkManagerImpl::CreateRootCompositorFrameSink() #14 0x7f604d3acb89 viz::mojom::FrameSinkManagerStubDispatch::Accept() #15 0x7f605a765e37 mojo::InterfaceEndpointClient::HandleValidatedMessage() #16 0x7f605a7656e6 mojo::FilterChain::Accept() #17 0x7f605a767302 mojo::InterfaceEndpointClient::HandleIncomingMessage() #18 0x7f605a7720c2 mojo::internal::MultiplexRouter::ProcessIncomingMessage() #19 0x7f605a771581 mojo::internal::MultiplexRouter::Accept() #20 0x7f605a7656e6 mojo::FilterChain::Accept() #21 0x7f605a75fd5d mojo::Connector::ReadSingleMessage() #22 0x7f605a7609f4 mojo::Connector::ReadAllAvailableMessages() #23 0x7f605a760856 mojo::Connector::OnHandleReadyInternal() #24 0x7f605a761194 mojo::SimpleWatcher::DiscardReadyState() #25 0x7f605a720df8 mojo::SimpleWatcher::OnHandleReady() #26 0x7f605a72138e _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo13SimpleWatcherEFvijRKNS3_18HandleSignalsStateEEJNS_7WeakPtrIS4_EEijS5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_ijS5_EEEJLm0ELm1ELm2ELm3EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE #27 0x7f605b4d0baa base::debug::TaskAnnotator::RunTask() #28 0x7f605b503a16 base::internal::IncomingTaskQueue::RunTask() #29 0x7f605b507b07 base::MessageLoop::RunTask() #30 0x7f605b507f24 base::MessageLoop::DeferOrRunPendingTask() #31 0x7f605b5081e8 base::MessageLoop::DoWork() #32 0x7f605b509680 base::MessagePumpDefault::Run() #33 0x7f605b50735c base::MessageLoop::Run() #34 0x7f605b53d416 base::RunLoop::Run() #35 0x7f605b57ff8a base::Thread::Run() #36 0x7f605b580583 base::Thread::ThreadMain() #37 0x7f605b57671f base::(anonymous namespace)::ThreadFunc() #38 0x7f605b61a184 start_thread #39 0x7f604e5bdffd clone r8: fefefefefefefeff r9: fefefefefeff092d r10: 0000000000000008 r11: 0000000000000206 r12: 00007f6050dd720d r13: 00007f6050dd76b0 r14: 0000154a62a06000 r15: 00007f603d1abf88 di: 000000000000509f si: 00000000000050c0 bp: 00007f604e644018 bx: 00007f604311c000 dx: 0000000000000006 ax: 0000000000000000 cx: 00007f604e4f6c37 sp: 00007f603d1abd78 ip: 00007f604e4f6c37 efl: 0000000000000206 cgf: 0000000000000033 erf: 0000000000000000 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] Calling _exit(1). Core file will not be generated. Crash from browser process: Received signal 11 SEGV_MAPERR 000000000000 #0 0x7f1bcb30c28c base::debug::StackTrace::StackTrace() #1 0x7f1bcb30bd61 base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7f1bcb45e330 <unknown> #3 0x7f1bc78fe5f3 cc::ResourceProvider::CreateBitmapResource() #4 0x7f1bc78fe27a cc::ResourceProvider::CreateResource() #5 0x7f1bc7902251 cc::ScopedResource::Allocate() #6 0x7f1bc78fa34b cc::ResourcePool::CreateResource() #7 0x7f1bc79484f3 cc::TileManager::CreateRasterTask() #8 0x7f1bc7945732 cc::TileManager::AssignGpuMemoryToTiles() #9 0x7f1bc7944c2f cc::TileManager::PrepareTiles() #10 0x7f1bc7971803 cc::LayerTreeHostImpl::PrepareTiles() #11 0x7f1bc7970610 cc::LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation() #12 0x7f1bc7970291 cc::LayerTreeHostImpl::CommitComplete() #13 0x7f1bc79ba12e cc::SingleThreadProxy::DoCommit() #14 0x7f1bc79bdd0c cc::SingleThreadProxy::ScheduledActionCommit() #15 0x7f1bc79110ac cc::Scheduler::ProcessScheduledActions() #16 0x7f1bc7911a6d cc::Scheduler::NotifyReadyToCommit() #17 0x7f1bc79bd6f4 cc::SingleThreadProxy::BeginMainFrame() #18 0x7f1bc79be41d _ZN4base8internal7InvokerINS0_9BindStateIMN2cc17SingleThreadProxyEFvRKN3viz14BeginFrameArgsEEJNS_7WeakPtrIS4_EES6_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE #19 0x7f1bcb30cbaa base::debug::TaskAnnotator::RunTask() #20 0x7f1bcb33fa16 base::internal::IncomingTaskQueue::RunTask() #21 0x7f1bcb343b07 base::MessageLoop::RunTask() #22 0x7f1bcb343f24 base::MessageLoop::DeferOrRunPendingTask() #23 0x7f1bcb3441e8 base::MessageLoop::DoWork() #24 0x7f1bcb345f0f base::(anonymous namespace)::WorkSourceDispatch() #25 0x7f1bbfe37e04 g_main_context_dispatch #26 0x7f1bbfe38048 <unknown> #27 0x7f1bbfe380ec g_main_context_iteration #28 0x7f1bcb345c42 base::MessagePumpGlib::Run() #29 0x7f1bcb34335c base::MessageLoop::Run() #30 0x7f1bcb379416 base::RunLoop::Run() #31 0x559e71aabfa7 ChromeBrowserMainParts::MainMessageLoopRun() #32 0x7f1bc896c027 content::BrowserMainLoop::RunMainMessageLoopParts() #33 0x7f1bc896f853 content::BrowserMainRunnerImpl::Run() #34 0x7f1bc8967e6a content::BrowserMain() #35 0x7f1bc93aa61b content::RunNamedProcessTypeMain() #36 0x7f1bc93ab0f6 content::ContentMainRunnerImpl::Run() #37 0x7f1bcb82c794 service_manager::Main() #38 0x7f1bc93a9961 content::ContentMain() #39 0x559e7158c1cc ChromeMain #40 0x7f1bbe31df45 __libc_start_main #41 0x559e7158c02a _start r8: 0000000000000000 r9: 00007fff6199a390 r10: 000000000000009c r11: 0000000000000000 r12: 0000288201b7fc40 r13: 0000000000000000 r14: 0000288202788518 r15: 00007fff6199a3c0 di: 0000288201b7fd58 si: 0000000000000000 bp: 00007fff619999b0 bx: 0000288202788518 dx: 0000288201b7fd58 ax: 0000000001b7fd01 cx: 4e5e4145bdbc0f01 sp: 00007fff61999730 ip: 00007f1bc78fe5f3 efl: 0000000000010202 cgf: 4e5e000000000033 erf: 0000000000000004 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] Calling _exit(1). Core file will not be generated.
,
Dec 6 2017
The second crash is something unimplemented and I believe danakj is working on. The first crash is expected and I will fix it.
,
Dec 6 2017
Issue 776613 needs to cherry pick these CLs for next stable release of ChromeOS.
,
Dec 6 2017
What CLs? This bug is for --enable-viz which is not enabled anywhere yet.
,
Dec 6 2017
,
Dec 6 2017
sorry for noise.
,
Dec 13 2017
Ok I am on a mission to kill SharedBitmap and SharedBitmapManager in the child processes. This is a complicated out-of-band system to map sharedbitmapids to shared memory handles.
The plan looks roughly like this:
CompositorFrameSink mojo interface gains two methods. This makes the notifications in-band with submitted compositor frames, eliminating races.
// Informs the display compositor that the child allocated a shared bitmap. The |id|
// can then be used in subsequent CompositorFrames given to SubmitCompositorFrame.
DidAllocateSharedBitmap(handle<shared_buffer> buffer, gpu.mojom.Mailbox id);
// Informs the display compositor that the child deleted a shared bitmap.
DidDeleteSharedBitmap(gpu.mojom.Mailbox id);
LayerTreeFrameSink also gains similar methods which pass through to the CompositorFrameSink.
// Associates a SharedBitmapId with a shared buffer handle.
virtual void DidAllocateSharedBitmap(mojo::ScopedSharedBufferHandle buffer,
const viz::SharedBitmapId& id) = 0;
// Disassociates a SharedBitmapId previously passed to
// DidAllocateSharedBitmap.
virtual void DidDeleteSharedBitmap(const viz::SharedBitmapId& id) = 0;
We remove all the sequence number tracking from RenderWidgetHostImpl. It is a CompositorFrameSink (for non-viz), so it grows a set of SharedBitmapIds, and informs the ServerSharedBitmapManager about allocations and deletions, and deletes * when it is Destroy()ed.
We do the same in CompositorFrameSinkSupport, and all CompositorFrameSinkImpls forward through to this.
Ok now things get interesting. Consumers of SharedBitmapManager in the child are, that I know so far:
- cc::LayerTreeHostImpl / cc::LayerTreeResourceProvider
These classes allocate shared bitmaps for raster. When they allocate then LayerTreeResourceProvider duplicates the shared memory handle (via ClientSharedBitmapManager) and ships ownership of it to the display compositor in an IPC.
Instead of doing this IPC through a separate IPC interface, we can keep track of all SharedMemory objects in the LayerTreeHostImpl, and dupe handles and send them to the CompositorFrameSink (and re-send when the CompositorFrameSink is replaced).
- blink::OffscreenCanvasResourceProvider
This class allocates shared memory and ships ownership of a duped handle to the display compositor via the Platform API which uses the ClientSharedBitmapManager on RenderThreadImpl. Since OffscreenCanvas has its own CompositorFrameSink, we can give the CompositorFrameSink pointer to the OffscreenCanvasResourceProvider, and have it notify about allocations directly to it.
- WebGL DrawingBuffer / Canvas ImageLayerBridge
This class also allocates shared memory and ships a dupled handle through the Platform API. However this code is a client of LayerTreeHost, and does not have its own CompositorFrameSink, nor access to LayerTreeHost's (wrong thread).
I think we can make use of the same system used for LayerTreeHostImpl/LayerTreeResourceProvider. We add an API to cc::LayerTreeHost to report creating/destroying shared memory - and we pass pointer-ownership of the shared memory in there, keeping lifetime-ownership via the SharedBitmapId in the WebGL/Canvas code. It gives the Id up to the LayerTreeHost to free the shared memory.
LayerTreeHost commits these shared memories over to LayerTreeHostImpl which dupes and passes ownership of a handle through the CompositorFrameSink (and re-does this when CompositorFrameSink is replaced).
- PepperGraphics2dHost
I think this is identical in spirit to the WebGL/Canvas cases, and can use the same APIs.
- RenderViewImpl Disambiguation popup
This shouldn't be using SharedBitmap, it's not for the compositor. http://crbug.com/790807.
- WebView SynchronousLayerTreeFrameSink
WebView uses a SharedBitmapManager to give to the SoftwareRenderer to allocate bitmaps with (thru ResourceProvider). This is all overkill http://crbug.com/692814. But for now we don't have to care yet. I believe we can instead instantiate a ServerSharedBitmapManager in the SynchronousLayerTreeFrameSink and give that to the Display, rather than getting a ClientSharedBitmapManager from the RenderThreadImpl. This should make things a bit more lightweight for almost free, as we'll stop using shared memory for that Display's resources, tho doesn't do much for the code complexity.
- ContentShell TestPlugin
TestPlugin works like Pepper/Canvas/WebGL, but doesn't go through the Platform API. I think we should be able to hook it up to the LayerTreeHost though like the others.
I think that's it. Off we go then, this will take at least a few patches. I am currently thinking to approach it something like:
1. WebView stop using ClientSharedBitmapManager
2. Build out the LayerTreeHost{Impl} stuff.
3. Hide SharedBitmapManager from LayerTreeResourceProvider, and have it use the stuff from 2.
4. Remove Platform API use for WebGL/Canvas/TestPlugin/Pepper and have them use the stuff from 2.
5. Add the replacement API on CompositorFrameSinks.
6. Convert LayerTreeHostImpl to use CompositorFrameSink instead of SharedBitmapManager.
7. Remove SharedBitmapManager from LayerTreeFrameSink.
8. Remove shared bitmap ID tracking from RenderWidgetHostImpl.
8. Convert OffscreeCanvas to use CompositorFrameSink instead of Platform API.
9. Remove Platform API.
10. Remove the SharedBitmapAllocationNotification mojo APIs/impl.
11. Remove ClientSharedBitmapManager.
12. Remove sequence numbers from SharedBitmap.
13. Make SharedBitmap into a viz-service-side-only simpler non-virtual thing (or delete it). Delete the SharedBitmapManager interface base class.
The end?
,
Dec 13 2017
Also ftr https://chromium-review.googlesource.com/c/chromium/src/+/802574 appears to be much harder to land than I thought, as RenderProcessHostImpls are made in lots of unit tests that don't have a BrowserMainLoop. Rather than do more intricate hacks, the above means there won't be a SharedBitmapAllocationNotificationImpl in RenderProcessHostImpl, which means removing the ServerSharedBitmapManager singleton existance from the browser process will be easier.
,
Dec 14 2017
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a2b00295495ed040ac9768266f15e9d142655dcc commit a2b00295495ed040ac9768266f15e9d142655dcc Author: danakj <danakj@chromium.org> Date: Thu Dec 14 22:36:22 2017 Give Webview SynchronousLayerTreeFrameSink a ServerSharedBitmapManager This removes its use of the ClientSharedBitmapManager in the renderer process, freeing up one use toward removing it. This also means the Display in the SynchronousLayerTreeFrameSink will not allocate shared memory for RenderPass resources, as the ServerSharedBitmapManager will use normal memory allocations. R=boliu@chromium.org Bug: 730660 Change-Id: Ibb05a8f1787a221351232907704412c5b682e85f Reviewed-on: https://chromium-review.googlesource.com/826182 Reviewed-by: Bo <boliu@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#524202} [modify] https://crrev.com/a2b00295495ed040ac9768266f15e9d142655dcc/content/renderer/android/DEPS [modify] https://crrev.com/a2b00295495ed040ac9768266f15e9d142655dcc/content/renderer/android/synchronous_layer_tree_frame_sink.cc [modify] https://crrev.com/a2b00295495ed040ac9768266f15e9d142655dcc/content/renderer/android/synchronous_layer_tree_frame_sink.h [modify] https://crrev.com/a2b00295495ed040ac9768266f15e9d142655dcc/content/renderer/render_thread_impl.cc
,
Dec 14 2017
Insert step 1.5 1.5: Get SoftwareRenderer and SkiaRenderer off ResourceProvider so that the LayerTreeHost/ResourceProvider interactions can be only on LayerTreeResourceProvider and not impact the Display compositor.
,
Dec 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b8d249cfeff9699c054f721e6c4f3a09dd345b8d commit b8d249cfeff9699c054f721e6c4f3a09dd345b8d Author: kylechar <kylechar@chromium.org> Date: Fri Dec 15 00:04:18 2017 viz: Call XInitThreads(). Both the GPU and compositor threads can make Xlib calls and XInitThreads() must be called in this situation. Change GPU process to always call XInitThreads() during startup. GLSurfaceGLX will still call XInitThreads() on startup because some test paths need it. XInitThreads() will return immediately for subsequent calls so this should be safe. Bug: 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I0f3b44d7ac1a0e6c9e711de6d457634435add101 Reviewed-on: https://chromium-review.googlesource.com/818054 Commit-Queue: kylechar <kylechar@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#524242} [modify] https://crrev.com/b8d249cfeff9699c054f721e6c4f3a09dd345b8d/content/gpu/BUILD.gn [modify] https://crrev.com/b8d249cfeff9699c054f721e6c4f3a09dd345b8d/content/gpu/gpu_main.cc
,
Dec 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/249dc2fe982d665760b5acfafb6b9eb62d0acd1f commit 249dc2fe982d665760b5acfafb6b9eb62d0acd1f Author: danakj <danakj@chromium.org> Date: Fri Dec 15 21:46:32 2017 Don't use ResourceProvider to make bitmaps in SoftwareRenderer The SoftwareRenderer doesn't need to share those bitmaps out of process so it can just make regular SkBitmaps and use those, without depending on ResourceProvider, ResourceIds, SharedBitmapManager, etc to get that done. R=kylechar@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ie49389776441efe3faddb7ecf364126e5cc44170 Reviewed-on: https://chromium-review.googlesource.com/828081 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#524472} [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/direct_renderer.cc [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/direct_renderer.h [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/gl_renderer.cc [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/gl_renderer.h [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/skia_renderer.cc [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/skia_renderer.h [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/software_renderer.cc [modify] https://crrev.com/249dc2fe982d665760b5acfafb6b9eb62d0acd1f/components/viz/service/display/software_renderer.h
,
Dec 19 2017
,
Dec 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c79b8c848fc4352c35f30cda3372b53e3c89df25 commit c79b8c848fc4352c35f30cda3372b53e3c89df25 Author: Antonio Gomes <tonikitoo@igalia.com> Date: Wed Dec 20 18:47:34 2017 fixup! viz: Spawn renderer with gpu disabled when it's turned off already. ImageTransportFactory doesn't exist in mus. Either ENABLE_MUS needs an ImageTransportFactory or ENABLE_MUS has to get the value from somewhere else. While this does not happen, extra harden the build time check to reflect the situation. BUG=730660 Change-Id: I6a93d426e19d6fe5cf797252434d56e53cdc95a1 Reviewed-on: https://chromium-review.googlesource.com/832146 Commit-Queue: Antonio Gomes <tonikitoo@igalia.com> Reviewed-by: kylechar <kylechar@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Cr-Commit-Position: refs/heads/master@{#525384} [modify] https://crrev.com/c79b8c848fc4352c35f30cda3372b53e3c89df25/content/browser/renderer_host/render_process_host_impl.cc
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/51329a3c86c6c89564b2777a3bbc1729024fa64d commit 51329a3c86c6c89564b2777a3bbc1729024fa64d Author: danakj <danakj@chromium.org> Date: Thu Dec 21 00:07:05 2017 Stop using ResourceProvider to create resources for SkiaRenderer. This drops a dependency on ResourceProvider to create new resources in the display compositor, allowing us to remove that functionality from the DisplayResourceProvider. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I7835e71b3c1657dcc28f4bb2bd093b3b1dae86ed Reviewed-on: https://chromium-review.googlesource.com/835353 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#525525} [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/direct_renderer.cc [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/direct_renderer.h [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/gl_renderer.cc [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/gl_renderer.h [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/skia_renderer.cc [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/skia_renderer.h [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/software_renderer.cc [modify] https://crrev.com/51329a3c86c6c89564b2777a3bbc1729024fa64d/components/viz/service/display/software_renderer.h
,
Dec 21 2017
Some more 1.5 steps: a. https://chromium-review.googlesource.com/c/chromium/src/+/838263 makes software resource creation explicit inside cc b. then we need to have ScopedResource be able to hold an imported resource, but to do that it needs to point to LayerTreeResourceProvider*. that depends on xing's patch to get GLRenderer off ScopedResource (soon) c. then we can make owners of software resources also own the SharedBitmap and make imported resources from them to get a resource id. At some point the GL resource creation could probably be abstracted out of LayerTreeResourceProvider too, and then it would just be imported resources?
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0ce8b0deb0f465cf40331dc5afc289b312ddefab commit 0ce8b0deb0f465cf40331dc5afc289b312ddefab Author: danakj <danakj@chromium.org> Date: Thu Dec 21 21:20:49 2017 Remove ResourceProvider::CreateResource, expose gpu/software choice. This changes the clients of ResourceProvider to create explicitly gpu or software resources, rather than hiding the choice inside CreateResource. This means software resources no longer have to pass in hints/formats that are fixed or don't apply. The purpose of this is to separate CreateBitmapResource() out so that the clients can in future work allocate and own the SharedBitmap themselves. At that point they can "import" software TransferableResources via SharedBitmapId the same way we do for clients of cc, and the creators of SharedBitmap can move off of SharedBitmap and SharedBitmapManager. Once that is done, we will notify SharedBitmapId creation through the CompositorFrameSink instead of through the SharedBitmapManager. R=piman@chromium.org NOTRY=true Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: If9bb98f9fc325c0c9652fee51f07628d4ebc328b Reviewed-on: https://chromium-review.googlesource.com/838263 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#525803} [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/layers/heads_up_display_layer_impl.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/layers/heads_up_display_layer_impl.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/layer_tree_resource_provider_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_pool.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_pool.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_provider.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_provider.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/resource_provider_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/scoped_resource.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/scoped_resource.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/scoped_resource_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/video_resource_updater.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/resources/video_resource_updater.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/test/fake_picture_layer_tiling_client.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/test/fake_ui_resource_layer_tree_host_impl.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/test/pixel_test.h [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/test/render_pass_test_utils.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/cc/trees/layer_tree_host_impl_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/components/viz/service/display/gl_renderer.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/components/viz/service/display/gl_renderer_unittest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/components/viz/service/display/renderer_pixeltest.cc [modify] https://crrev.com/0ce8b0deb0f465cf40331dc5afc289b312ddefab/components/viz/service/display/software_renderer_unittest.cc
,
Dec 22 2017
A random thought about moving creation/ownership of bitmaps out of ResourceProvider before the holidays. We could do the same for GL resources too. The reason they are owned inside ResourceProvider right now is so that they can outlive the ResourceId in the client, in order for them to be returned to a child later. This is not needed anymore for uses of ResourceProvider that create resources (ie LayerTreeResourceProvider). So we could put ownership in Tile/etc instead of in internal::Resource, and just make LayerTreeResourceProvider only deal in TransferableResources. That'd position it well for non-cc clients to make use of better too, probably.. and get texture creation code in a general place that could be shared by cc & viz & other viz clients & VideoResourceUpdater & etc? kbye.
,
Jan 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/52e1d55c1ef39797050456f93ca6681ada56fb63 commit 52e1d55c1ef39797050456f93ca6681ada56fb63 Author: danakj <danakj@chromium.org> Date: Thu Jan 04 01:39:21 2018 Replace use of ResourcePool with owned ScopedGpuMemoryBufferTexture ResourcePool makes uses of creating resources on ResourceProvider, which is a functionality of LayerTreeResourceProvider (ie compositor clients). We replace it with 3 vectors in GLRenderer, and ScopedGpuMemoryBufferTexture, of which ownership is moved through those vectors. ScopedGpuMemoryBufferTexture allocates a texture backed by an image + GpuMemoryBuffer, so that it can be used as an overlay. The first vector is the set of in-flight textures. Once SwapBuffersComplete happens, we move them to a set awaiting release from CA. Then on signal from CA we recycle them back into the available set. R=ccameron@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I24efe515b69aaa7ec30d7163f28a66f96c3562c0 Reviewed-on: https://chromium-review.googlesource.com/843127 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#526892} [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/cc/resources/resource_provider.cc [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/BUILD.gn [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/gl_renderer.cc [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/gl_renderer.h [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/gl_renderer_unittest.cc [modify] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/overlay_unittest.cc [add] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/scoped_gpu_memory_buffer_texture.cc [add] https://crrev.com/52e1d55c1ef39797050456f93ca6681ada56fb63/components/viz/service/display/scoped_gpu_memory_buffer_texture.h
,
Jan 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb commit bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb Author: danakj <danakj@chromium.org> Date: Thu Jan 04 17:47:20 2018 Give ScopedResource a LayerTreeResourceProvider. ScopedResource is used for making resources that will be shipped out of the layer tree compositor. Give it a LayerTreeResourceProvider so that we reduce the API surface needed by the ResourceProvider base class to not include creating/deleting these resources, and allowing us to change how software resource are created. R=piman@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ia89068da79c497539f4cbf98f96bba4b9f4d362b Reviewed-on: https://chromium-review.googlesource.com/848253 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#527028} [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/layers/heads_up_display_layer_impl.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/layers/heads_up_display_layer_impl.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/raster/gpu_raster_buffer_provider.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/raster/staging_buffer_pool.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/resource.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/resource_pool.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/resource_pool.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/scoped_resource.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/scoped_resource.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/resources/scoped_resource_unittest.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/test/fake_picture_layer_tiling_client.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/test/fake_picture_layer_tiling_client.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/tiles/picture_layer_tiling_set_unittest.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/tiles/tile.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/tiles/tile_draw_info.h [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/tiles/tile_manager.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/bf124ca1e2e80f27377cb2e0797f0fcccb56b0cb/components/viz/service/display/gl_renderer.cc
,
Jan 5 2018
,
Jan 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ee1b38ee2e5b4d2c086e6cd27dc679ca7a3cd87f commit ee1b38ee2e5b4d2c086e6cd27dc679ca7a3cd87f Author: danakj <danakj@chromium.org> Date: Fri Jan 05 21:11:19 2018 cc: Remove GetTextureHint() from ResourceProvider. The hint is used for making resources, but is not used after, and is not part of imported resources. As we transition toward using those, this method will not work. Also it's not used today. R=kylechar@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I7d52b48ee2ed47e6f5644236ab2953d8af2f4ee7 Reviewed-on: https://chromium-review.googlesource.com/852696 Reviewed-by: kylechar <kylechar@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#527381} [modify] https://crrev.com/ee1b38ee2e5b4d2c086e6cd27dc679ca7a3cd87f/cc/resources/resource_provider.cc [modify] https://crrev.com/ee1b38ee2e5b4d2c086e6cd27dc679ca7a3cd87f/cc/resources/resource_provider.h
,
Jan 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8870280cdda552bdb93cbd223ab511cf5f1fbefe commit 8870280cdda552bdb93cbd223ab511cf5f1fbefe Author: Weiliang Chen <weiliangc@chromium.org> Date: Wed Jan 10 20:01:13 2018 viz: Stop SkiaRenderer Reading RenderPass Textures from ResourceProvider SkiaRenderer creates and owns its render pass textures, should not read from ResourceProvider. This would have same behavior as other DirectRenderers. R=danakj@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I78db25a674600fe7288a6576e05cf3185057d01f Reviewed-on: https://chromium-review.googlesource.com/852974 Reviewed-by: enne <enne@chromium.org> Commit-Queue: weiliangc <weiliangc@chromium.org> Cr-Commit-Position: refs/heads/master@{#528398} [modify] https://crrev.com/8870280cdda552bdb93cbd223ab511cf5f1fbefe/components/viz/service/display/skia_renderer.cc
,
Jan 11 2018
,
Jan 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9bbf70d01e3ec2ab7868b38c660f7cf2f41c3d3f commit 9bbf70d01e3ec2ab7868b38c660f7cf2f41c3d3f Author: kylechar <kylechar@chromium.org> Date: Thu Jan 11 21:31:44 2018 viz: Work around for SharedBitmapManager crashes. Change VizProcessTransportFactory to provide a ServerSharedBitmapManager to newly created LayerTreeFrameSinks. The software compositing path currently crashes the browser process with --enable-viz because there is no SharedBitmapManager. This is a quick work around to avoid the crash. Software composited areas (eg. tooltips) will be blank until the refactor for SharedBitmap resources is finished. Bug: 730660 Change-Id: I1bdeeda9fed3a30583d7d9f5b70e8aa2a70d9843 Reviewed-on: https://chromium-review.googlesource.com/848395 Commit-Queue: kylechar <kylechar@chromium.org> Reviewed-by: Fady Samuel <fsamuel@chromium.org> Cr-Commit-Position: refs/heads/master@{#528761} [modify] https://crrev.com/9bbf70d01e3ec2ab7868b38c660f7cf2f41c3d3f/content/browser/compositor/viz_process_transport_factory.cc [modify] https://crrev.com/9bbf70d01e3ec2ab7868b38c660f7cf2f41c3d3f/content/browser/compositor/viz_process_transport_factory.h
,
Jan 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c42be6060ef48eef2942de0c6bf6c39852fd860f commit c42be6060ef48eef2942de0c6bf6c39852fd860f Author: danakj <danakj@chromium.org> Date: Wed Jan 17 17:22:31 2018 ResourcePool creation cleanups. - Use make_unique<T> instead of T::Create() - Set disallow_non_exact_resource_reuse in RenderWidgetCompositor instead of in the constructor when OS_ANDROID. - Remove disallow_non_exact_resource_reuse from RendererSettings since ResourcePool is not used there anymore. - Add a separate constructor for software resources instead of a bool since not all the gpu fields need to be given (the hint is not relevant). - Pass the task runner by scoped_refptr, since it will store it in one (same in StagingBufferPool). R=vmpstr@chromium.org TBR=kenrb Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I98803de7c4f99ce2f694fcd071a05d6cc1bbfe77 Reviewed-on: https://chromium-review.googlesource.com/852776 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#529785} [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/raster/one_copy_raster_buffer_provider.h [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/raster/staging_buffer_pool.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/raster/staging_buffer_pool.h [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/resources/resource_pool.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/resources/resource_pool.h [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/test/fake_picture_layer_tiling_client.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/components/viz/common/display/renderer_settings.h [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/components/viz/host/renderer_settings_creation.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/content/renderer/gpu/render_widget_compositor.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/services/viz/privileged/interfaces/compositing/renderer_settings.mojom [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/services/viz/privileged/interfaces/compositing/renderer_settings_struct_traits.cc [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/services/viz/privileged/interfaces/compositing/renderer_settings_struct_traits.h [modify] https://crrev.com/c42be6060ef48eef2942de0c6bf6c39852fd860f/services/viz/privileged/interfaces/struct_traits_unittest.cc
,
Jan 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4e871d8fb606cb411e2883be013479bddbc37837 commit 4e871d8fb606cb411e2883be013479bddbc37837 Author: danakj <danakj@chromium.org> Date: Thu Jan 18 21:56:57 2018 Vend resources from ResourcePool with an RAII object. This RAII object, InUsePoolResource wraps an underlying backing from the ResourcePool, and verifies at runtime that the object is passed back to the ResourcePool exactly once to indicate the backing is no longer in use and release it into the pool again. The RAII object exposes the backing but requires the caller to know if they are expecting a software or gpu backing when they ask for it. This means that TileManager can no longer try to access the backing, and must always go through the RasterBufferProvider. It was already doing this mostly, but the API was a bit lazy and leaked the backing info (the ResourceId) into TileManager in a couple places, so we must resolve that and make it use InUsePoolResource exclusively. PictureLayerImpl grabs a ResourceId off the TileDrawInfo as before, but it is explicitly marked as an id meant for export to the display compositor, as opposed to a backing that can be written to. For now the backing is still a ResourceId for both software/gpu and it is written to via the ResourceProvider locks, but this sets us up to be able to change that. R=vmpstr@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I79292834482a8d1a3858d61a8313f14b3221337e Reviewed-on: https://chromium-review.googlesource.com/868713 Reviewed-by: vmpstr <vmpstr@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#530286} [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/layers/picture_layer_impl.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/layers/picture_layer_impl_unittest.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/bitmap_raster_buffer_provider.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/bitmap_raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/gpu_raster_buffer_provider.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/gpu_raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/one_copy_raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/staging_buffer_pool.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/staging_buffer_pool.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/raster/zero_copy_raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/resources/resource_pool.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/resources/resource_pool.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/test/fake_raster_buffer_provider.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/test/fake_raster_buffer_provider.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile_draw_info.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile_draw_info.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile_manager.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile_manager.h [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/4e871d8fb606cb411e2883be013479bddbc37837/cc/trees/layer_tree_host_pixeltest_masks.cc
,
Jan 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2477ec97389f184f0e25750b4e2a277ff9189e9d commit 2477ec97389f184f0e25750b4e2a277ff9189e9d Author: danakj <danakj@chromium.org> Date: Mon Jan 29 18:12:43 2018 Don't purge busy resources from ResourcePool But drop them when they become available if we're in the SUSPENDED memory state. Deleting busy resorces doesn't actually free any memory, it just moves the ownership solely into the ResourceProvider until they become available. Instead, we can keep them in the busy list, and when they are available, decide to keep them or not based on the memory state instead. This should also improve things by reducing memory footprint in the SUSPENDED memory state if OnPurgeMemory() isn't being called but new tile resources are being made and released. R=ericrk@chromium.org, vmpstr@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I24e1a6f38c88fa278566849174a315bff71ed375 Reviewed-on: https://chromium-review.googlesource.com/886862 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Commit-Position: refs/heads/master@{#532492} [modify] https://crrev.com/2477ec97389f184f0e25750b4e2a277ff9189e9d/cc/resources/resource_pool.cc [modify] https://crrev.com/2477ec97389f184f0e25750b4e2a277ff9189e9d/cc/resources/resource_pool.h [modify] https://crrev.com/2477ec97389f184f0e25750b4e2a277ff9189e9d/cc/resources/resource_pool_unittest.cc
,
Jan 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/694134e2b295464c965306b2865250cd97173de2 commit 694134e2b295464c965306b2865250cd97173de2 Author: danakj <danakj@chromium.org> Date: Mon Jan 29 20:15:40 2018 Move ownership of software ResourcePool backings into the pool. Instead of the ResourcePool making a ResourceId, which the RasterBufferProvider implementation actualizes into a backing via a write lock, we have the ResourcePool give out a metadata object, and the RasterBufferProvider allocates a backing for it directly. Then, TileManager puts a ResourceId by explicitly asking the ResourcePool to do so, in order to allow the backing to be exported to the display compositor. R=vmpstr@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Idc3b127f819e7154414cb7de9897e5309a22b7bc Reviewed-on: https://chromium-review.googlesource.com/882101 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#532566} [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/raster/bitmap_raster_buffer_provider.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/raster/bitmap_raster_buffer_provider.h [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/resources/resource_pool.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/resources/resource_pool.h [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/tiles/tile_manager.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/694134e2b295464c965306b2865250cd97173de2/cc/trees/layer_tree_host_impl.cc
,
Jan 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6aea0ad7e72eb80da8eafcfb06dc231d987d5f2f commit 6aea0ad7e72eb80da8eafcfb06dc231d987d5f2f Author: danakj <danakj@chromium.org> Date: Mon Jan 29 21:28:59 2018 Add comments for RasterBufferProvider synchronization methods. Also adds comments explaining the implementation of them in OneCopyRasterBufferProvider. R=piman@chromium.org, sunnyps@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I02a762a4208fcd8d317c35c49f40d36425f27126 Reviewed-on: https://chromium-review.googlesource.com/891442 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#532594} [modify] https://crrev.com/6aea0ad7e72eb80da8eafcfb06dc231d987d5f2f/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/6aea0ad7e72eb80da8eafcfb06dc231d987d5f2f/cc/raster/raster_buffer_provider.h
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd63605c0b5cbcd45dd8320143b2d511f3112995 commit bd63605c0b5cbcd45dd8320143b2d511f3112995 Author: danakj <danakj@chromium.org> Date: Tue Feb 06 18:28:49 2018 Move ownership of ResourcePool zero-copy resources to buffer provider This adds a GpuBacking object to PoolResource, which holds ownership of all the GpuMemoryBuffer-based backing objects. The ZeroCopyRasterBufferImpl has a subclass with its own specific types in it, and populates them: a) When AcquireBufferForRaster is called it creates the GpuBacking and ensures the sync token is waited on if present. b) When the RasterBuffer is destroyed, back on the compositor thread, it binds the GpuMemoryBuffer to a mailbox, and stores those onto the GpuBacking. Then ResourcePool can export the GpuBacking by reading the mailbox of it. And when the resource is destroyed, the GpuBacking cleans up the ownership of the mailboxed texture and GpuMemoryBuffer. R=vmpstr@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Iac964108e2ab767239e9968e03f82bc80d6a6e3b Reviewed-on: https://chromium-review.googlesource.com/888844 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/heads/master@{#534726} [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/layers/texture_layer_impl.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/layers/texture_layer_unittest.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/raster/zero_copy_raster_buffer_provider.h [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/resources/layer_tree_resource_provider.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/resources/layer_tree_resource_provider_unittest.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/resources/resource_pool.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/resources/resource_pool.h [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/bd63605c0b5cbcd45dd8320143b2d511f3112995/cc/trees/layer_tree_host_impl.cc
,
Feb 8 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2c201ec3f0edf8d50fffd582a31ee4eb42b1713c commit 2c201ec3f0edf8d50fffd582a31ee4eb42b1713c Author: danakj <danakj@chromium.org> Date: Thu Feb 08 18:25:36 2018 Fix flakiness when dumping memory with ZeroCopyRasterBufferProvider The GpuBacking in a PoolResource is allocated before running the raster task, but the GpuMemoryBuffer is set on the backing after. If memory dump happens in between, it would crash trying to read the null GpuMemoryBuffer. Until the GpuMemoryBuffer is set, we can treat the memory as not allocated (from the compositor thread's perspective at the least). So change ResourcePool code to handle this case. R=vmpstr@chromium.org Bug: 730660, 810073 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I7b5add1f741c8596432f070e8c6038c69612540c Reviewed-on: https://chromium-review.googlesource.com/906672 Reviewed-by: vmpstr <vmpstr@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#535447} [modify] https://crrev.com/2c201ec3f0edf8d50fffd582a31ee4eb42b1713c/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/2c201ec3f0edf8d50fffd582a31ee4eb42b1713c/cc/resources/resource_pool.cc [modify] https://crrev.com/2c201ec3f0edf8d50fffd582a31ee4eb42b1713c/cc/resources/resource_pool.h
,
Feb 8 2018
,
Feb 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/af3170e5f40955165ffea7a5dd0d8032a9e012f5 commit af3170e5f40955165ffea7a5dd0d8032a9e012f5 Author: danakj <danakj@chromium.org> Date: Fri Feb 09 17:31:58 2018 Move ownership of gpu texture resources to ResourcePool This makes allocation of resources in OneCopyRasterBufferProvider and GpuRasterBufferProvider happen directly instead of through a ResourceProvider lock, and stores ownership of the resources in the ResourcePool. For each RasterBufferProvider, a) When AcquireBufferForRaster is called it creates the GpuBacking and ensures the sync token is waited on if present, and creates a texture and mailbox. b) After playback on the worker, a sync token is created. c) When the RasterBuffer is destroyed, back on the compositor thread, it stores that sync token into the GpuBacking. R=sunnyps@chromium.org, vmpstr@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ide0005262435cc4a0925766761221dc8852f0026 Reviewed-on: https://chromium-review.googlesource.com/895806 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Commit-Position: refs/heads/master@{#535741} [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/gpu_raster_buffer_provider.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/gpu_raster_buffer_provider.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/one_copy_raster_buffer_provider.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/resources/layer_tree_resource_provider.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/resources/layer_tree_resource_provider.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/resources/resource_pool.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/resources/resource_pool.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/test/fake_raster_buffer_provider.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/tiles/tile_manager.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/cc/trees/layer_tree_host_unittest.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/components/viz/common/BUILD.gn [add] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/components/viz/common/gpu/texture_allocation.cc [add] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/components/viz/common/gpu/texture_allocation.h [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/components/viz/common/resources/resource_format_utils.cc [modify] https://crrev.com/af3170e5f40955165ffea7a5dd0d8032a9e012f5/components/viz/common/resources/resource_format_utils.h
,
Feb 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/737d223066587b0e3be07ac84aafe6eb2733d3f4 commit 737d223066587b0e3be07ac84aafe6eb2733d3f4 Author: danakj <danakj@chromium.org> Date: Fri Feb 09 20:16:34 2018 Cleaning up ResourcePool TODOs. This drops some unused method/fields from ResourcePool and consolidates the constructors to a single one. R=vmpstr@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I7bd8483d177dde7b3b24a5490d15f3ea03502492 Reviewed-on: https://chromium-review.googlesource.com/895870 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#535805} [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/resources/resource_pool.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/resources/resource_pool.h [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/test/fake_picture_layer_tiling_client.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/tiles/tile_manager.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/737d223066587b0e3be07ac84aafe6eb2733d3f4/cc/trees/layer_tree_host_impl.cc
,
Feb 9 2018
,
Feb 13 2018
,
Feb 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/55243afdd78947ce52c81df834a5b7cc319c633a commit 55243afdd78947ce52c81df834a5b7cc319c633a Author: danakj <danakj@chromium.org> Date: Wed Feb 14 20:09:01 2018 cc: Move ownership of resources for the compositor HeadsUpDisplay This moves ownership of the HUD layer's resources out of the ResourceProvider to the HUD directly, with its own ResourcePool. Using a ResourcePool allows the HUD to reuse resources without rolling its own pool essentially. The HUD's textures are all dropped on ReleaseResources() which signals the context was no longer valid. But not released (still) on ReleaseTileResources(), which signals a change to/from gpu rasterization. Instead, change the signal to the HUD for using gpu raster to be based only on the gpu context, and not on the page content. R=enne@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I10cd0e786c4b7e98896ee138ecc3c5e5a8756162 Reviewed-on: https://chromium-review.googlesource.com/912112 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: enne <enne@chromium.org> Cr-Commit-Position: refs/heads/master@{#536791} [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/layers/heads_up_display_layer_impl.cc [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/layers/heads_up_display_layer_impl.h [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/layers/heads_up_display_layer_impl_unittest.cc [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/trees/layer_tree_impl.cc [modify] https://crrev.com/55243afdd78947ce52c81df834a5b7cc319c633a/cc/trees/layer_tree_impl.h
,
Feb 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/50fc16efa60869e2f49d5458810694479ed277f6 commit 50fc16efa60869e2f49d5458810694479ed277f6 Author: danakj <danakj@chromium.org> Date: Wed Feb 14 21:49:48 2018 Don't memory dump PoolResources until they have storage allocated. It's possible for TileManager to grab a resource from the pool, but then not use it. Also, until the raster task actually runs, there is no memory allocated. So don't return a guid until a texture id is created and storage is allocated for it. R=ericrk@chromium.org, vmpstr@chromium.org Bug: 811432,730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I9a33a66746c5c95a6ae9bdc363c784adbeb949bc Reviewed-on: https://chromium-review.googlesource.com/919313 Reviewed-by: vmpstr <vmpstr@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#536831} [modify] https://crrev.com/50fc16efa60869e2f49d5458810694479ed277f6/cc/raster/gpu_raster_buffer_provider.cc [modify] https://crrev.com/50fc16efa60869e2f49d5458810694479ed277f6/cc/raster/one_copy_raster_buffer_provider.cc
,
Feb 15 2018
Now that we're much further along here, looking over the next steps.. > - WebGL DrawingBuffer / Canvas ImageLayerBridge > > This class also allocates shared memory and ships a dupled handle through the Platform API. However this code is a > client of LayerTreeHost, and does not have its own CompositorFrameSink, nor access to LayerTreeHost's (wrong thread). > > I think we can make use of the same system used for LayerTreeHostImpl/LayerTreeResourceProvider. We add an API to > cc::LayerTreeHost to report creating/destroying shared memory - and we pass pointer-ownership of the shared memory in > there, keeping lifetime-ownership via the SharedBitmapId in the WebGL/Canvas code. It gives the Id up to the > LayerTreeHost to free the shared memory. > > LayerTreeHost commits these shared memories over to LayerTreeHostImpl which dupes and passes ownership of a handle > through the CompositorFrameSink (and re-does this when CompositorFrameSink is replaced). There's some problems here. The blink clients do not have a persistent connection to a single LayerTreeHost. They may not be attached to any at some times. They may want to allocate or delete shared memory at those times. Currently blink clients notify about shm thru RenderThreadImpl which they do have a persistent connection to (through Platform). Also, a blink client may move between different LTHs over its lifetime, which the TextureLayer would know about, but no new resource need be submitted when it happens.
,
Feb 15 2018
Some things considered/observed here are:
- We used to care about Shm allocation but that is no longer the case, all Shm allocation can be done anywhere through mojo now. What we care about it pairing a (duped) Shm handle to a SharedBitmapId that the display knows about/owns.
- We can't assume Shm is allocated inside TextureLayerClient::PrepareTransferableResource(), but we /could/ do the shm->id mapping in there. For other clients of TextureLayer that push updates, they would have to do the mapping through TextureLayer.
- We could make this look more like GL, where we have a software "context" that gets lost in blink with a callback when the CFS goes down and that we notify through. basically SharedBitmapAllocationNotifier directly to viz.
- I don't like this because unlike GL where the the display queues things into a command buffer, and can insert waits there, software is done directly. It has to actually wait for the IPCs. Right now we do that in RenderWidgetHostImpl by sitting on compositor frames, but we'd have to build that into the viz CompositorFrameSinkImpl stuff instead.. and delay CompositorFrameSinks from being received. Or activated?
- I'm trying really hard to find a way to put this IPC on CompositorFrameSink so it's in the same channel as the SubmitCompositorFrame calls.
Something like this would allow the client to name the SharedBitmapId to the Shm handle when it had a new handle.
virtual bool PrepareTransferableResource(
SharedBitmapIdAllocator* allocator,
viz::TransferableResource* out_transferable_resource,
std::unique_ptr<viz::SingleReleaseCallback>* out_release_callback) = 0;
And an accessor on TextureLayer to the same allocator for push clients.
With
class SharedBitmapIdAllocation {
SharedBitmapId Id();
~SharedBitmapIdAllocation() { ... has ptr to CFS to unnotify ... }
};
class SharedBitmapIdAllocator {
// cc client keeps this allocation alive as long as it wants to use the shm/sharedbitmapid in compositor frames
SharedBitmapIdAllocation Allocate(base::SharedMemory*) { .. notifies thru the CFS .. }
};
However the SharedBitmapIdAllocation needs to basically be implemented inside TextureLayer, so it can know about the LayerTreeHost changing. And also telling the LayerTreeHost to un-notify the display about the id (to let it delete its shared bitmap handle) when the allocation is destroyed.
The cc client needs to keep the allocation alive for a shm handle until the ReleaseCallback for the shm it sent, and continue to keep it alive if it wants to reuse the shm, or make a new one on the next time it wants a SharedBitmapId for the shm handle in a TransferableResource.
The SharedBitmapIdAllocation is kinda complicated, idk. It's doable, tightly coupled to the TextureLayer which is the place where it is needed.
,
Feb 15 2018
The other nice thing IMO about putting this onto CompositorFrameSink is it makes things the simplest for the desired path. Surface clients like video-surfaces, offscreen canvas, and cc, have a CompositorFameSink and can do the simple thing. Notify when they make a shm, and when they delete it. There is no synchronization penalties imposed on them with shared bitmap sequence numbers, and sitting on their compositor frames due to bad IPC scheduling. This only complicates clients going thru TextureLayer which is the undesirable/deprecated path, with them dancing thru some hoops and pointery helper classes.
,
Feb 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/96f593847f8811bfe8977f82b1c343880e222300 commit 96f593847f8811bfe8977f82b1c343880e222300 Author: danakj <danakj@chromium.org> Date: Sun Feb 18 21:37:25 2018 Fix rebasing in ResourcePool's OnMemoryDump. This went all wrong, with a branch being duplicated and comments to variables that no longer exist. R=ericrk@chromium.org TBR=ericrk Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Iaf5d331798ed2b4343c57120e558546c40489b63 Reviewed-on: https://chromium-review.googlesource.com/919661 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#537567} [modify] https://crrev.com/96f593847f8811bfe8977f82b1c343880e222300/cc/resources/resource_pool.cc
,
Feb 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/abc59ef67aad37a5e929cb5e98bcfca4890ffb77 commit abc59ef67aad37a5e929cb5e98bcfca4890ffb77 Author: danakj <danakj@chromium.org> Date: Tue Feb 20 20:54:13 2018 Make ResourcePool export the resource format on TransferableResource This format isn't part of the TransferableResource::MakeFoo() helpers but is important nonetheless for memory accounting, and would be important for software resources. For GL the format is known in the service so it ends up not being used for correctness. R=ericrk@chromium.org Bug: 811432, 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ibaacf987cbbdb1cc17ad624325c843aca7ba7230 Reviewed-on: https://chromium-review.googlesource.com/927021 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Commit-Position: refs/heads/master@{#537874} [modify] https://crrev.com/abc59ef67aad37a5e929cb5e98bcfca4890ffb77/cc/resources/resource_pool.cc [modify] https://crrev.com/abc59ef67aad37a5e929cb5e98bcfca4890ffb77/components/viz/common/resources/transferable_resource.h
,
Feb 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/729d39efe011c30ab04a68905c0d3b1e173224f1 commit 729d39efe011c30ab04a68905c0d3b1e173224f1 Author: danakj <danakj@chromium.org> Date: Tue Feb 20 21:18:48 2018 OneCopy resources should not be allocated for framebuffer attachment The ResourcePool used to be created for OneCopy mode with a kDefault ResourceTextureHint, rather than kFramebuffer. This was a copy-paste from GpuRasterBufferProvider, which does want to use textures for framebuffer attachment. R=vmpstr@chromium.org Bug: 811432, 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ibfba07d0f8834ecdd7160d5e80d8e4d5bb544706 Reviewed-on: https://chromium-review.googlesource.com/926723 Reviewed-by: Eric Karl <ericrk@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#537883} [modify] https://crrev.com/729d39efe011c30ab04a68905c0d3b1e173224f1/cc/raster/one_copy_raster_buffer_provider.cc
,
Feb 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/63c438c49a4f3ff93c58f2ecf955bb18952eae81 commit 63c438c49a4f3ff93c58f2ecf955bb18952eae81 Author: danakj <danakj@chromium.org> Date: Tue Feb 20 23:51:44 2018 Export BufferFormat and fence requirements for zero copy resources Zero-copy resources use a GpuMemoryBuffer, so they have a BufferFormat that is determined by the resource format + usage. This format is used to determine if the resource can be promoted to an overlay or not. Also, zero-copy resources require a fence to know when they are no longer in use before trying to write to them in the renderer, when the resource is reused. This is because they are written to directly outside of the command stream, so they shouldn't be returned to the renderer until it is okay for it to do so. R=ericrk@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I7ac389bf8f3b6f9e5c8a3802e5f7e5fb48872e31 Reviewed-on: https://chromium-review.googlesource.com/927161 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Commit-Position: refs/heads/master@{#537939} [modify] https://crrev.com/63c438c49a4f3ff93c58f2ecf955bb18952eae81/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/63c438c49a4f3ff93c58f2ecf955bb18952eae81/cc/resources/resource_pool.cc [modify] https://crrev.com/63c438c49a4f3ff93c58f2ecf955bb18952eae81/cc/resources/resource_pool.h [modify] https://crrev.com/63c438c49a4f3ff93c58f2ecf955bb18952eae81/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/63c438c49a4f3ff93c58f2ecf955bb18952eae81/components/viz/common/resources/transferable_resource.h
,
Feb 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c8ab25a7851ba87c989a69874ab9b96b1cc8945 commit 1c8ab25a7851ba87c989a69874ab9b96b1cc8945 Author: danakj <danakj@chromium.org> Date: Wed Feb 21 17:58:04 2018 Invalidate resources in ResourcePool when moving to/from gpu raster Instead of destroying and recreating the ResourcePool (which can drop resources in-flight to the display compositor), just invalidate any resources in the pool so they will not be reused. We only need to recreate the ResourcePool when we have a new context and ResourceProvider. It used to be the case that the pool held states related to gpu raster (the texture allocation hint), but it is no longer the case, so the pool can continue to be used, just not any resources previously allocated. R=enne@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I0d58f40501c08984d1380c1f2b572ad56571186c Reviewed-on: https://chromium-review.googlesource.com/927323 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: enne <enne@chromium.org> Cr-Commit-Position: refs/heads/master@{#538150} [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/resources/resource_pool.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/resources/resource_pool.h [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/test/layer_tree_pixel_resource_test.h [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/test/layer_tree_test.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/test/test_hooks.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/test/test_hooks.h [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/1c8ab25a7851ba87c989a69874ab9b96b1cc8945/cc/trees/layer_tree_host_impl.h
,
Feb 22 2018
,
Feb 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b1c319a39c52519e5516c56ee735a040448a272a commit b1c319a39c52519e5516c56ee735a040448a272a Author: danakj <danakj@chromium.org> Date: Fri Feb 23 00:10:50 2018 viz: Add mojo to give SharedBitmapId mappings on CompositorFrameSink. This method is in the same pipe as SubmitCompositorFrame() so that we can get correct ordering - if a SharedBitmapId is posted, then a CompositorFrame is submitted, we don't have a race of using the frame before the bitmap id arrives. The implementations give the SharedBitmapId to the ServerSharedBitmapManager. For tests, which have other SharedBitmapManager types, we have to add these methods to the SharedBitmapManager interface. The mojo interface is not used by anything in this CL, but we will migrate from ClientSharedBitmapManager to this in future CLs. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: Iec3a8fe24860f5f2a8090ce4e3c8b4ad3ea3b00c Reviewed-on: https://chromium-review.googlesource.com/929643 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#538631} [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/DEPS [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/test/fake_layer_tree_frame_sink.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/test/fake_layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/test/test_shared_bitmap_manager.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/test/test_shared_bitmap_manager.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/trees/layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/cc/trees/layer_tree_frame_sink_unittest.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/client/client_layer_tree_frame_sink.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/client/client_layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/client/client_shared_bitmap_manager.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/client/client_shared_bitmap_manager.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/common/resources/DEPS [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/common/resources/shared_bitmap_manager.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/display_embedder/server_shared_bitmap_manager_unittest.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/compositor_frame_sink_impl.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/compositor_frame_sink_impl.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/compositor_frame_sink_support.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/compositor_frame_sink_support.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/direct_layer_tree_frame_sink.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/direct_layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/root_compositor_frame_sink_impl.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/service/frame_sinks/root_compositor_frame_sink_impl.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/test/DEPS [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/components/viz/test/test_layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/content/renderer/android/synchronous_layer_tree_frame_sink.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/content/renderer/android/synchronous_layer_tree_frame_sink.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/services/ui/ws/compositor_frame_sink_client_binding.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/services/ui/ws/compositor_frame_sink_client_binding.h [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/services/ui/ws/frame_generator_unittest.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/services/viz/public/interfaces/compositing/compositor_frame_sink.mojom [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/third_party/WebKit/Source/platform/graphics/VideoFrameSubmitterTest.cpp [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/ui/aura/local/layer_tree_frame_sink_local.cc [modify] https://crrev.com/b1c319a39c52519e5516c56ee735a040448a272a/ui/aura/local/layer_tree_frame_sink_local.h
,
Feb 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d1dd03155abe26c9b1c7bcba580c2b8de406310f commit d1dd03155abe26c9b1c7bcba580c2b8de406310f Author: danakj <danakj@chromium.org> Date: Fri Feb 23 18:13:46 2018 Remove RasterBufferProvider::OrderingBarrier. Instead, make a SyncToken when generating the gpu::Mailbox for each (new) resource. If a resource is reused from the ResourcePool, then no SyncToken will be be generated. Previously we always called OrderingBarrier and inserted a SyncToken each time we prepared tiles for raster, even if the resources were reused. R=sunnyps@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I4bdf5ab00f82fe8a9eed56f5cabc6628c1dffc22 Reviewed-on: https://chromium-review.googlesource.com/909070 Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#538822} [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/bitmap_raster_buffer_provider.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/bitmap_raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/gpu_raster_buffer_provider.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/gpu_raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/one_copy_raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/zero_copy_raster_buffer_provider.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/raster/zero_copy_raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/test/fake_raster_buffer_provider.cc [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/test/fake_raster_buffer_provider.h [modify] https://crrev.com/d1dd03155abe26c9b1c7bcba580c2b8de406310f/cc/tiles/tile_manager.cc
,
Feb 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a721b029b31640e26db86b12f9e5fd149e19aefb commit a721b029b31640e26db86b12f9e5fd149e19aefb Author: danakj <danakj@chromium.org> Date: Fri Feb 23 22:11:11 2018 cc: Give ResourcePool a unique tracing id. There may be more than one ResourcePool in a process, so a unique id is needed to name each resource in memory dumps. Previously it used the id on the ResourceProvider which is unique to each layer compositor instance. But now there are more than one ResourcePool within the same layer compositor, as the HUD layer can have its own ResourcePool, so invent a tracing id specifically for ResourcePool. This also handily removes another dependency on ResourceProvider that isn't needed for exporting resources to the display compositor. R=enne@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I09427437427eb2ec1df6a40aa73d9624c004d0a6 Reviewed-on: https://chromium-review.googlesource.com/935423 Reviewed-by: enne <enne@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#538916} [modify] https://crrev.com/a721b029b31640e26db86b12f9e5fd149e19aefb/cc/resources/resource_pool.cc [modify] https://crrev.com/a721b029b31640e26db86b12f9e5fd149e19aefb/cc/resources/resource_pool.h
,
Feb 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/512888750425d7bdca95a780bc7b4214ea959556 commit 512888750425d7bdca95a780bc7b4214ea959556 Author: danakj <danakj@chromium.org> Date: Sat Feb 24 00:22:28 2018 viz: Remove SharedBitmaps from ServerSharedBitmapManager on disconnect When a renderer or other viz client shuts down, the CompositorFrameSink may not have been notified about all the SharedBitmapIds being deleted. In that case the shared memory would stay in the display compositor's ServerSharedBitmapManager forever, leaking that memory space. So have each CompositorFrameSink implementation remember what SharedBitmapIds it has told the display compositor about, and remove them all when the implementation is destroyed. R=kylechar@chromium.org NOTRY=true Bug: 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ia1aff6f9035b4713ece787f49ceb1d6c0f839c15 Reviewed-on: https://chromium-review.googlesource.com/929989 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#538957} [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/components/viz/service/frame_sinks/compositor_frame_sink_support.cc [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/components/viz/service/frame_sinks/compositor_frame_sink_support.h [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/components/viz/test/test_layer_tree_frame_sink.h [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/512888750425d7bdca95a780bc7b4214ea959556/content/browser/renderer_host/render_widget_host_impl.h
,
Feb 26 2018
,
Feb 27 2018
,
Mar 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cf8851712041012f32241f38dd960c1d0ad11229 commit cf8851712041012f32241f38dd960c1d0ad11229 Author: danakj <danakj@chromium.org> Date: Wed Mar 07 01:37:32 2018 viz: Make SharedBitmap tracing consistent and more clear Make SharedBitmap return an UnguessableToken as the shared bitmap-based tracing id, if the SharedBitmap is in fact backed by shared memory for cross-process use. This means ClientSharedBitmapManager always does and ServerSharedBitmapManager returns null if the bitmap was allocated inside the ServerSharedBitmapManager. In ServerSharedBitmapManager memory dumps, if a bitmap is shared memory backed, it dumps the |mapped_id()| which is the UnguessableToken. Otherwise, it dumps the SharedBitmapGUID from the SharedBitmapId. In ResourceProvider, if the SharedBitmap has an UnguessableToken for its shared memory backing, it dumps that, else uses the SharedBitmapID to make a GUID. In ResourcePool, the same thing is done as ResourceProvider. Thus, all child-process bitmaps will be dumped via the shared memory mapped_id() which is an UnguessableToken. And all service-process bitmaps are dumped via the SharedBitmapGUID. R=ericrk@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Id4b1c20350a139d36df13743d012756181937c6e Reviewed-on: https://chromium-review.googlesource.com/935428 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Commit-Position: refs/heads/master@{#541275} [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/cc/resources/resource_pool.cc [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/cc/resources/resource_provider.cc [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/components/viz/client/client_shared_bitmap_manager.cc [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/components/viz/common/quads/shared_bitmap.h [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/components/viz/service/display_embedder/server_shared_bitmap_manager_unittest.cc [modify] https://crrev.com/cf8851712041012f32241f38dd960c1d0ad11229/components/viz/test/test_shared_bitmap_manager.cc
,
Mar 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550 commit 1ab62f15e76dffbf3a7de3f2c37ad6008fa06550 Author: danakj <danakj@chromium.org> Date: Wed Mar 07 18:20:48 2018 cc: Allocate shared mem directly in BitmapRasterBufferProvider Previously this code used ClientSharedBitmapManager to allocate shared memory which would report the allocations thru the mojo-based SharedBitmapAllocationNotifier to the display compositor. But we want to tell the display compositor on the CompositorFrameSink so it is in the same channel as SubmitCompositorFrame. So BitmapRasterBufferProvider now receives a LayerTreeFrameSink instead of a SharedBitmapManager, does allocation of shared memory through base+mojo, and reports the allocations and destructions to the CompositorFrameSink. The ResourcePool and its resources are all destroyed before the CompositorFrameSink, so it can hold a raw pointer to the frame sink in each SoftwareBacking to notify when the shared memory is freed. This doesn't break the old notification path, and clients of ClientSharedBitmapManager will still notify their SharedBitmapIds to the display compositor with SharedBitmapAllocationNotifier, and with a valid sequence number. However for the BitmapRasterBufferProvider+ResourcePool, the sequence numbers are now 0 since they are not needed, as the notification goes to the same interface as SubmitCompositorFrame and will be well ordered. Notably, this means that the browser compositor's software resources will be allocated in shared memory, as the BitmapRasterBufferProvider and the CompositorFrameSink have no interface to pass raw pointers to the display. This is required for the VizDisplayCompositor feature, and as we close the shared memory fds it shouldn't greatly impact the browser process. R=kylechar@chromium.org TBR=sky Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I8354b11344afa58866105e970a0efc9741294b50 Reviewed-on: https://chromium-review.googlesource.com/935266 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#541506} [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/layers/heads_up_display_layer_impl.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/layers/heads_up_display_layer_impl.h [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/layers/heads_up_display_layer_impl_unittest.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/raster/bitmap_raster_buffer_provider.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/raster/bitmap_raster_buffer_provider.h [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/resources/resource_pool.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/resources/resource_pool.h [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/test/layer_tree_pixel_resource_test.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/client/client_shared_bitmap_manager.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/common/BUILD.gn [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/common/resources/DEPS [add] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/common/resources/bitmap_allocation.cc [add] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/common/resources/bitmap_allocation.h [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/test/test_shared_bitmap_manager.cc [modify] https://crrev.com/1ab62f15e76dffbf3a7de3f2c37ad6008fa06550/components/viz/test/test_shared_bitmap_manager.h
,
Mar 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24 commit 7cb0b3a36f2bea7a70d86cb923a77a07732a6e24 Author: kylechar <kylechar@chromium.org> Date: Wed Mar 07 22:19:46 2018 viz: Fix software compositing fallback. Make VizProcessTransportFactory software fallback work similar to GpuProcessTransportFactory software fallback. The major change here is that VizProcessTransportFactory includes the compositing mode in RootCompositorFrameSinkParams and code is unified. Delete ForwardingCompositingModeReporterImpl as it's no longer needed. Bug: 819474, 730660 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I2b6f53b41e4e0ac599fda0e3abeae77cfd69f0a9 Reviewed-on: https://chromium-review.googlesource.com/938329 Reviewed-by: Tom Sepez <tsepez@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#541607} [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/host/BUILD.gn [delete] https://crrev.com/82d6a7b47d69152cf6bd7cbc5985c5891de71a8d/components/viz/host/forwarding_compositing_mode_reporter_impl.cc [delete] https://crrev.com/82d6a7b47d69152cf6bd7cbc5985c5891de71a8d/components/viz/host/forwarding_compositing_mode_reporter_impl.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/display_embedder/display_provider.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/display_embedder/gpu_display_provider.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/display_embedder/gpu_display_provider.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/frame_sinks/frame_sink_manager_impl.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/main/viz_main_impl.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/service/main/viz_main_impl.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/test/test_display_provider.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/components/viz/test/test_display_provider.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/browser_main_loop.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/browser_main_loop.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/compositor/viz_process_transport_factory.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/compositor/viz_process_transport_factory.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/gpu/gpu_process_host.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/content/browser/gpu/gpu_process_host.h [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/services/ui/ws/window_server.cc [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/services/viz/privileged/interfaces/compositing/frame_sink_manager.mojom [modify] https://crrev.com/7cb0b3a36f2bea7a70d86cb923a77a07732a6e24/services/viz/privileged/interfaces/viz_main.mojom
,
Mar 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/df9e9205a243d3636eacf55f57445601896fcb22 commit df9e9205a243d3636eacf55f57445601896fcb22 Author: kylechar <kylechar@chromium.org> Date: Sat Mar 10 02:23:57 2018 Re-order VideoResourceUpdater methods. The order of methods has gotten pretty messy over the years. Reorder source file so its free functions, public functions then private functions and follows the order in header. Also fix header to be more style guide compliant. No change to any code beyond order and formatting. This is an initial step before refactoring resource allocation code. Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I6b36a8119c7c70e6981a24c56562b7e0ac2a504c Reviewed-on: https://chromium-review.googlesource.com/957556 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#542321} [modify] https://crrev.com/df9e9205a243d3636eacf55f57445601896fcb22/cc/resources/video_resource_updater.cc [modify] https://crrev.com/df9e9205a243d3636eacf55f57445601896fcb22/cc/resources/video_resource_updater.h
,
Mar 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/272ecf9b2994dec3d0dee9fae609cd821f5e157f commit 272ecf9b2994dec3d0dee9fae609cd821f5e157f Author: danakj <danakj@chromium.org> Date: Fri Mar 16 00:20:01 2018 cc: Move Resource size methods to viz This moves the ResourceUtil methods and the SharedBitmap methods to determine bytes from sizes to viz/common so they can be used in viz code. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I1c12896a3f87f8f577fb4aaf32239aa5a1baecb0 Reviewed-on: https://chromium-review.googlesource.com/954229 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#543570} [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/BUILD.gn [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/raster/one_copy_raster_buffer_provider.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/raster/staging_buffer_pool.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/layer_tree_resource_provider.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/resource_pool.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/resource_pool_unittest.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/resource_provider.cc [delete] https://crrev.com/672d71b45aad7b32830d880159a5c144f777ba39/cc/resources/resource_util.h [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/resource_util_unittest.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/resources/video_resource_updater.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/tiles/tile.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/tiles/tile_manager.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/BUILD.gn [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/quads/shared_bitmap.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/quads/shared_bitmap.h [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/resources/DEPS [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/resources/bitmap_allocation.cc [add] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/common/resources/resource_sizes.h [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/service/display_embedder/server_shared_bitmap_manager_unittest.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/components/viz/service/display_embedder/software_output_device_win.cc [modify] https://crrev.com/272ecf9b2994dec3d0dee9fae609cd821f5e157f/content/renderer/pepper/pepper_graphics_2d_host.cc
,
Mar 19 2018
We're going to need to add something to make VideoSurfaceUpdater work in two different configurations. 1. Normal video where LayerTreeFrameSink is used to notify the display compositor about SharedMemory allocations and deletions. 2. UseSurfaceLayerForVideo feature where there is no LayerTreeFrameSink and there is a mojom::CompositorFrameSinkSupport. Maybe another interface that has DidAllocateSharedBitmap() / DidDeleteSharedBitmap() that LayerTreeFrameSink and something else can extend?
,
Mar 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7731912933030a6f905b4c3528b0994655bd37c5 commit 7731912933030a6f905b4c3528b0994655bd37c5 Author: kylechar <kylechar@chromium.org> Date: Mon Mar 19 19:44:53 2018 Modernize and add comments for VideoResourceUpdater. This CL improves the code quality in VideoResourceUpdater. 1. Use C++11/14 conventions if possible. 2. Use OnceCallback and use member functions. 2. Delete dead code. 3. Add comments. Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: I6d34839b7b781fa61b3b7c6655f7bba599892755 Reviewed-on: https://chromium-review.googlesource.com/959046 Commit-Queue: kylechar <kylechar@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#544131} [modify] https://crrev.com/7731912933030a6f905b4c3528b0994655bd37c5/cc/resources/video_resource_updater.cc [modify] https://crrev.com/7731912933030a6f905b4c3528b0994655bd37c5/cc/resources/video_resource_updater.h
,
Mar 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f77a89225113b8f47f36670265fb9130502170ca commit f77a89225113b8f47f36670265fb9130502170ca Author: danakj <danakj@chromium.org> Date: Tue Mar 20 21:02:53 2018 Allocate shared memory/textures directly for UIResources. Instead of allocating through the ResourceProvider, allocate directly and store the backing on the UIResourceData in LayerTreeHostImpl. When deleted, stick them into a deleted_ui_resources_ list awaiting the display compositor to release them. At that point then free the backing texture/shared memory. This notifies SharedBitmapIds to the display compositor through the LayerTreeFrameSink instead of using SharedBitmapManager and bitmap sequence numbers. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Ib0704e9d9d878a22b8e481f2942ece0ac2a9f7f5 Reviewed-on: https://chromium-review.googlesource.com/953386 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#544516} [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/cc/test/fake_ui_resource_layer_tree_host_impl.cc [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/cc/test/fake_ui_resource_layer_tree_host_impl.h [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/cc/trees/layer_tree_host_impl.h [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/components/viz/common/gpu/texture_allocation.cc [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/components/viz/common/gpu/texture_allocation.h [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/components/viz/common/resources/resource_format_utils.cc [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/components/viz/common/resources/resource_format_utils.h [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/ui/gfx/OWNERS [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/ui/gfx/skia_util.cc [modify] https://crrev.com/f77a89225113b8f47f36670265fb9130502170ca/ui/gfx/skia_util.h
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/df9d6f301f2f79230b215d32ec9b2fe227e849dd commit df9d6f301f2f79230b215d32ec9b2fe227e849dd Author: kylechar <kylechar@chromium.org> Date: Thu Mar 22 20:25:54 2018 Change how VideoResourceUpdater allocates resources. Change VideoResourceUpdater to not allocates resources via LayerTreeResourceProvider. The resources are allocated directly and then imported to LayerTreeResourceProvider. For software resources SharedBitmapManager is no longer used. VideoResourceUpdater allocates SharedMemory directly and then notifies the display compositor via LayerTreeFrameSink. This new system will work with the VizDisplayCompositor feature. The new software compositing path doesn't work with the UseSurfaceLayerForVideo feature. This needs to be fixed eventually, but software compositing was already broken with UseSurfaceLayerForVideo and the feature is automatically disabled in that case. VideoResourceUpdater has the software and GPU compositing paths cleaned up. Both code paths work roughly the same now which simplifies the logic slightly. Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I840f5610248d9727c3d998669dd52f34d9cd1058 Reviewed-on: https://chromium-review.googlesource.com/956968 Reviewed-by: Justin Novosad <junov@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#545223} [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/layers/video_layer_impl.cc [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/resources/video_resource_updater.cc [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/resources/video_resource_updater.h [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/resources/video_resource_updater_unittest.cc [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/trees/layer_tree_impl.cc [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/cc/trees/layer_tree_impl.h [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/components/viz/service/display/renderer_pixeltest.cc [modify] https://crrev.com/df9d6f301f2f79230b215d32ec9b2fe227e849dd/third_party/WebKit/Source/platform/graphics/VideoFrameResourceProvider.cpp
,
Mar 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/493ecd31aa357359f421e5464ae3faca1e322a28 commit 493ecd31aa357359f421e5464ae3faca1e322a28 Author: danakj <danakj@chromium.org> Date: Thu Mar 22 23:28:56 2018 viz: Close the SharedMemory in DuplicateAndCloseMappedBitmap() This was an oversight, and we'll be keeping the shared memory for each tile in the compositor open with an fd in the renderer without this. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: I4f7b5d0c7ff9d2c63925a03232b23647a8ce3c2e Reviewed-on: https://chromium-review.googlesource.com/976650 Reviewed-by: kylechar <kylechar@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#545287} [modify] https://crrev.com/493ecd31aa357359f421e5464ae3faca1e322a28/components/viz/common/resources/bitmap_allocation.cc
,
Mar 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3ed7e609c3bfba1ea48d9f0347c9570481f57426 commit 3ed7e609c3bfba1ea48d9f0347c9570481f57426 Author: Mostyn Bramley-Moore <mostynb@vewd.com> Date: Fri Mar 23 11:46:40 2018 [jumbo] avoid g_next_tracing_id collision in video_resource_updater.cc Followup to https://chromium-review.googlesource.com/c/chromium/src/+/956968 TBR=danakj@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Idbfbf4702784e3af51298c95a2d1e45fd5f54096 Reviewed-on: https://chromium-review.googlesource.com/976882 Reviewed-by: Mostyn Bramley-Moore <mostynb@vewd.com> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#545406} [modify] https://crrev.com/3ed7e609c3bfba1ea48d9f0347c9570481f57426/cc/resources/video_resource_updater.cc
,
Mar 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0d9e184db7646b2ac744260ec9d26c3d2819921e commit 0d9e184db7646b2ac744260ec9d26c3d2819921e Author: kylechar <kylechar@chromium.org> Date: Tue Mar 27 12:49:16 2018 Cleanup VideoResourceUpdaterTests. 1. Consolidate logic to create VideoResourceUpdater into helper functions. 2. Improve ResourceType enum readability. 3. Delete dead code. 4. Fix software compositing tests expectations to ensure no new shared bitmap allocations. Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I1c4120b511a4e411f2699462eb03d9843a85c0a3 Reviewed-on: https://chromium-review.googlesource.com/977891 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#546089} [modify] https://crrev.com/0d9e184db7646b2ac744260ec9d26c3d2819921e/cc/resources/video_resource_updater.cc [modify] https://crrev.com/0d9e184db7646b2ac744260ec9d26c3d2819921e/cc/resources/video_resource_updater.h [modify] https://crrev.com/0d9e184db7646b2ac744260ec9d26c3d2819921e/cc/resources/video_resource_updater_unittest.cc [modify] https://crrev.com/0d9e184db7646b2ac744260ec9d26c3d2819921e/components/viz/service/display/renderer_pixeltest.cc
,
Mar 28 2018
,
Mar 29 2018
,
Mar 29 2018
,
Mar 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92d63896e496e23dcbedacd873fc37b8be8a5df6 commit 92d63896e496e23dcbedacd873fc37b8be8a5df6 Author: danakj <danakj@chromium.org> Date: Thu Mar 29 23:43:28 2018 cc: Notify SharedBitmapIds through TextureLayer, and use it for WebGL This adds an interface SharedBitmapIdRegistrar which is implemented by TextureLayer, and given to the TextureLayerClient directly in PrepareTransferableResource(). The SharedBitmapIdRegistrar is given mappings from viz::SharedBitmapId to base::SharedMemory objects. This mapping is kept valid as the TextureLayer moves between trees, or if the LayerTreeFrameSink changes, until the returned SharedBitmapIdRegistration is destroyed/assigned to. In order to maintain the mapping, the base::SharedMemory ownership must be at least partly held inside the TextureLayer, so this introduces a lightweight thread-safe ref-counted wrapper around the base::SharedMemory called CrossThreadSharedBitmap, that is used to give ownership to the TextureLayer, as well as to keep ownership in the client until it is no longer using the SharedMemory and any pending ReleaseCallbacks have fired. This plumbs the new SharedBitmapIdRegistrar to all clients of TextureLayer, but most don't touch it, still using the SharedBitmapManager to create/map their SharedMemory+SharedBitmapIds. The one client this does convert is WebGL, in the DrawingBuffer class. The class now holds a cc::CrossThreadSharedBitmap and cc::SharedBitmapIdRegistration instead of the viz::SharedBitmap it held previously. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I25e2bc6b819fcab043faa3fc4949a89f5e078307 Reviewed-on: https://chromium-review.googlesource.com/976694 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Cr-Commit-Position: refs/heads/master@{#547024} [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/BUILD.gn [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer_client.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer_impl.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer_impl.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/layers/texture_layer_unittest.cc [add] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/resources/cross_thread_shared_bitmap.cc [add] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/resources/cross_thread_shared_bitmap.h [add] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/resources/shared_bitmap_id_registrar.cc [add] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/cc/resources/shared_bitmap_id_registrar.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/components/viz/common/resources/bitmap_allocation.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/components/viz/common/resources/bitmap_allocation.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/components/viz/test/test_layer_tree_frame_sink.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/components/viz/test/test_shared_bitmap_manager.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/content/browser/compositor/reflector_impl_unittest.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/content/renderer/pepper/pepper_plugin_instance_impl.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/content/renderer/pepper/pepper_plugin_instance_impl.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/content/shell/test_runner/test_plugin.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/content/shell/test_runner/test_plugin.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/gpu/command_buffer/common/mailbox.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/gpu/command_buffer/common/mailbox.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferSoftwareRenderingTest.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferTest.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/ImageLayerBridge.cpp [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/third_party/WebKit/Source/platform/graphics/gpu/ImageLayerBridge.h [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/ui/compositor/layer.cc [modify] https://crrev.com/92d63896e496e23dcbedacd873fc37b8be8a5df6/ui/compositor/layer.h
,
Apr 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/61a9f19ac1e21a4fe9dcb1cf84cc2790d2367a58 commit 61a9f19ac1e21a4fe9dcb1cf84cc2790d2367a58 Author: danakj <danakj@chromium.org> Date: Mon Apr 02 20:03:58 2018 layout tests: Use SharedBitmapIdRegistrar for TestPlugin. This uses the new TextureLayer APIs to register SharedBitmapIds instead of using ClientSharedBitmapManager, in order to get the registration in the same IPC channel that the compositor uses for submitting frames that include the TestPlugin's shared memory bitmaps. The formula used for this change is: - Change std::unique_ptr<viz::SharedBitmap> to scoped_refptr<cc::CrossThreadSharedBitmap> - Allocate shm with viz::bitmap_allocation instead of with viz::SharedBitmapManager - Generate a SharedBitmapId when allocating and register it with SharedBitmapIdRegistrar - Store ownership of cc::SharedBitmapIdRegistration alongside each cc::CrossThreadSharedBitmap - Remove forward decls/includes for SharedBitmap and SharedBitmapManager (still need for SharedBitmapId) However, for TestPlugin a SharedMemory, and thus, a SharedBitmapId, is only given to the compositor a single time ever, and deleted in the ReleaseCallback. As well the SharedMemory is allocated earlier than when it is given to the compositor. So the SharedBitmapId registration is delated from the allocation step to where the SharedMemory is handed to the compositor. But since we only use a SharedMemory once, we can always do the registration there without any conditions. R=piman@chromium.org Bug: 730660 Change-Id: Idaf69b854062482f55d359f7542f576be7df1dd4 Reviewed-on: https://chromium-review.googlesource.com/987096 Commit-Queue: Antoine Labour <piman@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#547501} [modify] https://crrev.com/61a9f19ac1e21a4fe9dcb1cf84cc2790d2367a58/content/shell/test_runner/test_plugin.cc [modify] https://crrev.com/61a9f19ac1e21a4fe9dcb1cf84cc2790d2367a58/content/shell/test_runner/test_plugin.h
,
Apr 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/623e1c5e152cb642c8ca4599eabe2abb781f39c7 commit 623e1c5e152cb642c8ca4599eabe2abb781f39c7 Author: danakj <danakj@chromium.org> Date: Mon Apr 02 20:15:28 2018 pepper: Use SharedBitmapIdRegistrar for Pepper2d. This uses the new TextureLayer APIs to register SharedBitmapIds instead of using ClientSharedBitmapManager, in order to get the registration in the same IPC channel that the compositor uses for submitting frames that include the Pepper2d shared memory bitmaps. The formula used for this change is: - Change std::unique_ptr<viz::SharedBitmap> to scoped_refptr<cc::CrossThreadSharedBitmap> - Allocate shm with viz::bitmap_allocation instead of with viz::SharedBitmapManager - Generate a SharedBitmapId when allocating and register it with SharedBitmapIdRegistrar - Store ownership of cc::SharedBitmapIdRegistration alongside each cc::CrossThreadSharedBitmap - Remove forward decls/includes for SharedBitmap and SharedBitmapManager (still need for SharedBitmapId) R=piman@chromium.org Bug: 730660 Change-Id: I6018650bde54e966bae07a6621055c9f5eece648 Reviewed-on: https://chromium-review.googlesource.com/986985 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#547506} [modify] https://crrev.com/623e1c5e152cb642c8ca4599eabe2abb781f39c7/content/renderer/pepper/pepper_graphics_2d_host.cc [modify] https://crrev.com/623e1c5e152cb642c8ca4599eabe2abb781f39c7/content/renderer/pepper/pepper_graphics_2d_host.h [modify] https://crrev.com/623e1c5e152cb642c8ca4599eabe2abb781f39c7/content/renderer/pepper/pepper_plugin_instance_impl.cc
,
Apr 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9429976d3b2bea58a884e9e374178331fbb7b5b7 commit 9429976d3b2bea58a884e9e374178331fbb7b5b7 Author: danakj <danakj@chromium.org> Date: Mon Apr 02 21:50:58 2018 ui: Disallow software-backed TransferableResources in ui::Layer. The SetTransferableResource path used to be used for renderer compositor frames, but those go directly to the display compositor now. Instead it is used in a couple ChromeOS-specific cases: reflector, and rotation animation, where ChromeOS takes a screenshot and inserts it into another ui::Compositor. Since software resources aren't needed, document this in a comment, and with a DCHECK, and then no need to add SharedBitmapId registration code. R=kylechar@chromium.org Bug: 730660 Change-Id: I1312c4e58a84431bad1d4c5e23432784ccd206fa Reviewed-on: https://chromium-review.googlesource.com/987113 Commit-Queue: Antoine Labour <piman@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#547531} [modify] https://crrev.com/9429976d3b2bea58a884e9e374178331fbb7b5b7/ui/compositor/layer.cc [modify] https://crrev.com/9429976d3b2bea58a884e9e374178331fbb7b5b7/ui/compositor/layer.h
,
Apr 16 2018
I talked with junov@ and Canvas2DLayerBridge isn't used with software compositing. Hardware compositing is a perquisite for it, so doesn't need to implement the new SharedBitmapRegistrar API for TextureLayerClients.
,
Apr 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c934ee45176cd21a97be327e5e25ca019d16049 commit 4c934ee45176cd21a97be327e5e25ca019d16049 Author: kylechar <kylechar@chromium.org> Date: Wed Apr 18 16:48:29 2018 Use SharedBitmapIdRegistrar with ImageLayerBridge. This uses the new TextureLayer APIs to register SharedBitmapIds instead of using ClientSharedBitmapManager, in order to get the registration in the same IPC channel that the compositor uses for submitting frames that include the ImageLayerBridge's shared memory bitmaps. This CL also fixes a bug where bitmap data wasn't properly copied into shared memory. All rows from the source were copied into the same row of the destination. This was causing the canvas to appear (almost?) all black when using software compositing. I've tested the fix with https://codepen.io/anon/pen/qoeQEE which looks the same using GPU and software compositing. Bug: 730660, 831303 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: Ibf778947a68c5948596f5dd516606937a8c5c442 Reviewed-on: https://chromium-review.googlesource.com/1014380 Reviewed-by: Justin Novosad <junov@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: kylechar <kylechar@chromium.org> Cr-Commit-Position: refs/heads/master@{#551718} [modify] https://crrev.com/4c934ee45176cd21a97be327e5e25ca019d16049/third_party/blink/renderer/platform/graphics/gpu/image_layer_bridge.cc [modify] https://crrev.com/4c934ee45176cd21a97be327e5e25ca019d16049/third_party/blink/renderer/platform/graphics/gpu/image_layer_bridge.h
,
Apr 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7f5968d2dd21d93bbd94b6366d5017582876629a commit 7f5968d2dd21d93bbd94b6366d5017582876629a Author: Saman Sami <samans@chromium.org> Date: Thu Apr 19 13:13:41 2018 viz: Track latency info when software compositing is enabled The latency info given to SoftwareOutputSurface::SwapBuffers is currently ignored. Similar to GlOutputSurface, we should pass the the latency info to ui::LatencyTracker so it can collect UMA data. Verified on my workstation that histograms start showing up in chrome://histograms after this change. Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: If7130c12e4d6804072f05e4115b7e87aee186ff9 Reviewed-on: https://chromium-review.googlesource.com/1017341 Commit-Queue: Saman Sami <samans@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#551996} [modify] https://crrev.com/7f5968d2dd21d93bbd94b6366d5017582876629a/components/viz/service/display_embedder/software_output_surface.cc [modify] https://crrev.com/7f5968d2dd21d93bbd94b6366d5017582876629a/components/viz/service/display_embedder/software_output_surface.h
,
Apr 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9a61fc0fed553a6c152437a059120c96ea653790 commit 9a61fc0fed553a6c152437a059120c96ea653790 Author: danakj <danakj@chromium.org> Date: Thu Apr 19 19:08:26 2018 Register SharedMemory through CompositorFrameSink for OffscreenCanavas This converts from using the SharedBitmapManager, which registers shared memory through its own parallel channel, to allocating SharedMemory directly and reporting it to the CompositorFrameSink. The SharedBitmapManager path was racey with the submission of CompositorFrames, unless sequence numbers were used (they were not in this code), and required the display compositor to live in the browser process. With this change, OffscreenCanvas will work with viz software compositing. R=kylechar@chromium.org Bug: 730660 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I0daa654112e9834a325754ade37d19325793e01e Reviewed-on: https://chromium-review.googlesource.com/1017316 Reviewed-by: Justin Novosad <junov@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#552106} [modify] https://crrev.com/9a61fc0fed553a6c152437a059120c96ea653790/third_party/blink/renderer/platform/DEPS [modify] https://crrev.com/9a61fc0fed553a6c152437a059120c96ea653790/third_party/blink/renderer/platform/graphics/offscreen_canvas_frame_dispatcher_impl.cc [modify] https://crrev.com/9a61fc0fed553a6c152437a059120c96ea653790/third_party/blink/renderer/platform/graphics/offscreen_canvas_frame_dispatcher_impl.h [modify] https://crrev.com/9a61fc0fed553a6c152437a059120c96ea653790/third_party/blink/renderer/platform/graphics/offscreen_canvas_resource_provider.cc [modify] https://crrev.com/9a61fc0fed553a6c152437a059120c96ea653790/third_party/blink/renderer/platform/graphics/offscreen_canvas_resource_provider.h
,
Apr 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c097dc25dd99c4b80f490eba8231f5a212496d3d commit c097dc25dd99c4b80f490eba8231f5a212496d3d Author: danakj <danakj@chromium.org> Date: Thu Apr 19 19:21:31 2018 Remove most unused plumbing of SharedBitmapManager in renderer This removes the SharedBitmapManager API from content::RenderThread and blink::Platform, and plumbing of the type through content and blink. The class is no longer used for bitmap allocation on these paths, so it is not needed. R=pdr@chromium.org, piman@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I358328ad9495299462b32a576f3b8a7ca6d50a31 Reviewed-on: https://chromium-review.googlesource.com/1018141 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#552113} [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/cc/resources/video_resource_updater.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/public/renderer/render_thread.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/public/test/mock_render_thread.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/public/test/mock_render_thread.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/renderer/media/media_factory.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/renderer/render_thread_impl.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/renderer/render_thread_impl.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/renderer/renderer_blink_platform_impl.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/renderer/renderer_blink_platform_impl.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/shell/renderer/layout_test/blink_test_runner.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/shell/renderer/layout_test/blink_test_runner.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/shell/test_runner/web_test_delegate.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/test/test_blink_web_unit_test_support.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/content/test/test_blink_web_unit_test_support.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/public/platform/platform.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/public/platform/web_video_frame_submitter.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/renderer/platform/exported/web_video_frame_submitter.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/renderer/platform/graphics/video_frame_resource_provider.cc [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/renderer/platform/graphics/video_frame_resource_provider.h [modify] https://crrev.com/c097dc25dd99c4b80f490eba8231f5a212496d3d/third_party/blink/renderer/platform/graphics/video_frame_submitter_test.cc
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e2c1314045b9ec07100d46c4c4902d0e852cc436 commit e2c1314045b9ec07100d46c4c4902d0e852cc436 Author: danakj <danakj@chromium.org> Date: Fri Apr 20 02:14:03 2018 cc: Remove LayerTreeResourceProvider::CreateBitmapResource For unit tests, replace it with an ImportResource() of some arbitrary TransferableResource. For pixel tests, use viz::bitmap_allocation to allocate a bitmap, and SkBitmap::readPixels to populate the SharedMemory for the resource. Then register the SharedBitmapId with the display compositor via the SharedBitmapManager directly, and ImportResource() to make a ResourceId pointing to the SharedBitmapId for use in DrawQuads. R=piman@chromium.org Bug: 730660, 738190 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I143996712ee6477634d728a767f9095b5be8d74c Reviewed-on: https://chromium-review.googlesource.com/1020226 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#552232} [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/resources/layer_tree_resource_provider.cc [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/resources/layer_tree_resource_provider.h [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/resources/layer_tree_resource_provider_unittest.cc [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/test/pixel_test.cc [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/test/pixel_test.h [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/cc/trees/layer_tree_host_impl_unittest.cc [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/components/viz/service/display/renderer_pixeltest.cc [modify] https://crrev.com/e2c1314045b9ec07100d46c4c4902d0e852cc436/components/viz/service/display/software_renderer_unittest.cc
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e338d465398f6fa356032b4e1cd047071486f93e commit e338d465398f6fa356032b4e1cd047071486f93e Author: danakj <danakj@chromium.org> Date: Fri Apr 20 17:30:52 2018 cc: Remove SharedBitmapManager plumbing from cc. Add an instance of SharedBitmapManager for the display compositor on TestLayerTreeFrameSink. Remove all plumbing into cc for the SharedBitmapManager. R=piman@chromium.org TBR=pdr@chromium.org, sky@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: Iafdb85431051d51d70960390201c7d9d0a0a9c93 Reviewed-on: https://chromium-review.googlesource.com/1020369 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#552367} [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/layers/texture_layer_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/display_resource_provider_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/layer_tree_resource_provider.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/layer_tree_resource_provider.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/layer_tree_resource_provider_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/resource_provider_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/resources/video_resource_updater_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/fake_layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/fake_layer_tree_frame_sink.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/fake_resource_provider.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/layer_tree_pixel_test.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/layer_tree_test.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/layer_tree_test.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/test/pixel_test.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/tiles/picture_layer_tiling_set_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_frame_sink.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_frame_sink_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_host_impl_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_host_perftest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_host_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_host_unittest_context.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_impl.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/cc/trees/layer_tree_impl.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/client/client_layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/client/client_layer_tree_frame_sink.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/display/gl_renderer_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/display/overlay_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/display/software_renderer_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/frame_sinks/direct_layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/frame_sinks/direct_layer_tree_frame_sink.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/service/frame_sinks/direct_layer_tree_frame_sink_unittest.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/components/viz/test/test_layer_tree_frame_sink.h [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/browser/compositor/gpu_process_transport_factory.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/browser/compositor/viz_process_transport_factory.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/browser/renderer_host/compositor_impl_android.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/renderer/android/synchronous_layer_tree_frame_sink.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/renderer/render_thread_impl.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/content/test/layouttest_support.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/third_party/blink/renderer/platform/graphics/video_frame_resource_provider.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/ui/aura/local/layer_tree_frame_sink_local.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/ui/aura/test/aura_test_context_factory.cc [modify] https://crrev.com/e338d465398f6fa356032b4e1cd047071486f93e/ui/compositor/test/in_process_context_factory.cc
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9f746624b53296e9d5b967ce74e3604093226ad0 commit 9f746624b53296e9d5b967ce74e3604093226ad0 Author: danakj <danakj@chromium.org> Date: Fri Apr 20 18:39:22 2018 Register SharedBitmapIds through TextureLayer for PepperCompositorHost Replace usage of SharedBitmapManager with instead registering the SharedMemory and SharedBitmapId through the TextureLayer that they will be presented on. This gets the registration to go through the CompositorFrameSink which is compatable with the VizDisplayCompositor. R=piman@chromium.org Bug: 730660 Change-Id: I55f915eb00082ba527a440956e93cbf46acf7ce6 Reviewed-on: https://chromium-review.googlesource.com/1021838 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#552407} [modify] https://crrev.com/9f746624b53296e9d5b967ce74e3604093226ad0/content/renderer/pepper/pepper_compositor_host.cc [modify] https://crrev.com/9f746624b53296e9d5b967ce74e3604093226ad0/content/renderer/pepper/pepper_compositor_host.h
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/428a186027aa31e414d1fe7f0ef9b6c99085e103 commit 428a186027aa31e414d1fe7f0ef9b6c99085e103 Author: danakj <danakj@chromium.org> Date: Fri Apr 20 23:19:00 2018 Remove client-side APIs for SharedBitmapManager SharedBitmapManager is now a service-side only concept, so remove all client-side APIs. This includes the ClientSharedBitmapManager, the SharedBitmapAllocationNotifier mojo and c++ APIs, and the allocation method (and impls) in {Server,Test}SharedBitmapManager. Also removes the instance and bindings for these things from the renderer process in RenderThreadImpl, and the service-side connections in RenderProcessHost{Impl}. R=piman@chromium.org TBR=groby Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia976eb0e2a805c8e00803291214d346423315914 Reviewed-on: https://chromium-review.googlesource.com/1022180 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#552516} [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/cc/layers/texture_layer_unittest.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/cc/resources/display_resource_provider_unittest.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/cc/resources/resource_provider_unittest.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/chrome/browser/spellchecker/spellcheck_service_browsertest.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/client/BUILD.gn [delete] https://crrev.com/0adfd8cbc6dbe003fb2aa8bfce99298e749c7911/components/viz/client/client_shared_bitmap_manager.cc [delete] https://crrev.com/0adfd8cbc6dbe003fb2aa8bfce99298e749c7911/components/viz/client/client_shared_bitmap_manager.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/common/resources/shared_bitmap_manager.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/service/BUILD.gn [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/service/display_embedder/server_shared_bitmap_manager_unittest.cc [delete] https://crrev.com/0adfd8cbc6dbe003fb2aa8bfce99298e749c7911/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.cc [delete] https://crrev.com/0adfd8cbc6dbe003fb2aa8bfce99298e749c7911/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/test/test_shared_bitmap_manager.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/components/viz/test/test_shared_bitmap_manager.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/browser/renderer_host/render_process_host_impl.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/browser/renderer_host/render_process_host_impl.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/public/app/mojo/content_browser_manifest.json [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/public/browser/render_process_host.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/public/test/mock_render_process_host.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/public/test/mock_render_process_host.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/renderer/pepper/pepper_compositor_host.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/renderer/render_thread_impl.cc [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/content/renderer/render_thread_impl.h [modify] https://crrev.com/428a186027aa31e414d1fe7f0ef9b6c99085e103/services/viz/public/interfaces/BUILD.gn [delete] https://crrev.com/0adfd8cbc6dbe003fb2aa8bfce99298e749c7911/services/viz/public/interfaces/compositing/shared_bitmap_allocation_notifier.mojom
,
Apr 23 2018
,
Apr 23 2018
,
Apr 23 2018
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/db77408740a478b9553f49ee85470b0fb65906d9 commit db77408740a478b9553f49ee85470b0fb65906d9 Author: danakj <danakj@chromium.org> Date: Mon Apr 23 19:15:07 2018 viz: Remove sequence numbers from TransferableResource. These numbers are no longer used as SharedBitmapId registration happens in the same mojo ipc stream as CompositorFrameSubmission. So they don't need to exist anymore. R=kenrb@chromium.org, pdr@chromium.org, piman@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I12fcb70963cfaeebc5ae439ab3eb74dab1486bcd Reviewed-on: https://chromium-review.googlesource.com/1022294 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/master@{#552784} [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/ipc/cc_param_traits_macros.h [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/layers/texture_layer_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/resources/display_resource_provider_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/resources/layer_tree_resource_provider_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/resources/resource_pool.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/resources/resource_provider_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/resources/video_resource_updater.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/test/pixel_test.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/cc/trees/layer_tree_host_impl_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/components/viz/common/resources/transferable_resource.h [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/components/viz/service/display/renderer_pixeltest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/components/viz/service/display/software_renderer_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/content/renderer/pepper/pepper_compositor_host.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/content/renderer/pepper/pepper_graphics_2d_host.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/content/shell/test_runner/test_plugin.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/services/viz/public/cpp/compositing/struct_traits_unittest.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/services/viz/public/cpp/compositing/transferable_resource_struct_traits.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/services/viz/public/cpp/compositing/transferable_resource_struct_traits.h [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/services/viz/public/interfaces/compositing/transferable_resource.mojom [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.cc [modify] https://crrev.com/db77408740a478b9553f49ee85470b0fb65906d9/third_party/blink/renderer/platform/graphics/gpu/image_layer_bridge.cc
,
Apr 23 2018
,
May 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/acc082799b19bdda6fd257f96cefd662fddccdab commit acc082799b19bdda6fd257f96cefd662fddccdab Author: Christopher Cameron <ccameron@chromium.org> Date: Sat May 05 15:08:37 2018 viz/mac: Enable software compositing There exists plumbing to send gfx::CALayerParams (the parameters for displaying content on macOS) from the viz::Display to the browser process via that viz::DisplayClient interface. In GPU compositing, this comes in via viz::Display's implementation of viz::OutputSurfaceClient::DidReceiveCALayerParams. Make viz::Display also implement a new interface, viz::SoftwareOutputDeviceClient, and add a method to this interface, SoftwareDeviceUpdatedCALayerParams, which the SoftwareOutputDeviceMac calls when a frame is drawn. Route this to the same paths that the GPU compositing path takes to send it to the browser process. Delete the now-unneeded gfx::AcceleratedWidgetMac interfaces in SoftwareOutputDeviceMac. Bug: 730660, 772576 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: I03a21c5b1c1e5333aec94b5a0d1e88811fbbaf34 Reviewed-on: https://chromium-review.googlesource.com/1042312 Reviewed-by: kylechar <kylechar@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#556332} [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display/display.cc [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display/display.h [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display/software_output_device.cc [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display/software_output_device.h [add] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display/software_output_device_client.h [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display_embedder/gpu_display_provider.cc [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display_embedder/software_output_device_mac.cc [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display_embedder/software_output_device_mac.h [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/components/viz/service/display_embedder/software_output_device_mac_unittest.mm [modify] https://crrev.com/acc082799b19bdda6fd257f96cefd662fddccdab/content/browser/compositor/gpu_process_transport_factory.cc
,
May 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7167a9eac9d0f32675540f8ba623c601538c413e commit 7167a9eac9d0f32675540f8ba623c601538c413e Author: danakj <danakj@chromium.org> Date: Thu May 31 15:25:10 2018 viz: Remove the global ServerSharedBitmapManager. This moves ownership of the ServerSharedBitmapManager from a global variable accessed thru a static current() method, to be a member on BrowserMainLoop. This way random files can't instantiate a ServerSharedBitmapManager by calling a static method, when there should not even be one in the browser process with --enable-viz. A SharedBitmapManager* is given to the FrameSinkManagerImpl which always lives in the viz service process. The CompositorFrameSink implementations can grab the pointer from there in order to register software compositing bitmaps with the manager. R=kylechar@chromium.org, piman@chromium.org NOTRY=true Bug: 730660, 722935 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I4c5be0a22ecef9d98012104b8e46678e8cd76617 Reviewed-on: https://chromium-review.googlesource.com/802574 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Bo <boliu@chromium.org> Reviewed-by: Khushal <khushalsagar@chromium.org> Reviewed-by: kylechar <kylechar@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#563241} [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/android_webview/browser/surfaces_instance.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/client/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/common/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/host/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/host/host_frame_sink_manager_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display/display_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display/surface_aggregator_perftest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display/surface_aggregator_pixeltest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display/surface_aggregator_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display_embedder/gpu_display_provider.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display_embedder/gpu_display_provider.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/compositor_frame_sink_support.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/compositor_frame_sink_support_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/direct_layer_tree_frame_sink_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/frame_sink_manager_impl.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/frame_sink_manager_impl.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/frame_sink_manager_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/surface_references_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/surface_synchronization_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/frame_sinks/video_detector_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/hit_test/hit_test_aggregator_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/hit_test/hit_test_manager_fuzzer.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/main/viz_main_impl.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/main/viz_main_impl.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/surfaces/surface_hittest_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/service/surfaces/surface_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/browser_main_loop.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/browser_main_loop.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/compositor/gpu_process_transport_factory.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/compositor/gpu_process_transport_factory.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/compositor/test/test_image_transport_factory.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/compositor/test/test_image_transport_factory.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/renderer_host/compositor_impl_android.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/renderer_host/embedded_frame_sink_provider_impl_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/content/renderer/android/synchronous_layer_tree_frame_sink.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/third_party/blink/renderer/platform/graphics/offscreen_canvas_resource_provider.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/android/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/android/delegated_frame_host_android_unittest.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/aura/BUILD.gn [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/aura/demo/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/aura/demo/demo_main.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/compositor/test/context_factories_for_test.cc [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/views/examples/BUILD.gn [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/views/examples/DEPS [modify] https://crrev.com/7167a9eac9d0f32675540f8ba623c601538c413e/ui/views/examples/examples_main.cc
,
May 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eef1642efc2494c74ae177de5d858e0ddc3e72f2 commit eef1642efc2494c74ae177de5d858e0ddc3e72f2 Author: danakj <danakj@chromium.org> Date: Thu May 31 15:32:51 2018 viz: Remove thread-safety from ServerSharedBitmapManager Auditing ServerSharedBitmapManager thread usage: GetSharedBitmapFromId() called by: - DisplayResourceProvider::LockForRead - GLRenderer, SkiaRenderer, SoftwareRenderer (non-viz: UI, viz: Compositor) ChildAllocatedSharedBitmap() called by: - CompositorFrameSinkSupport::DidAllocateSharedBitmap (non-viz: UI, viz: Compositor) - RenderWidgetHostImpl::DidAllocateSharedBitmap (non-viz: UI, viz: Compositor) ChildDeletedSharedBitmap() called by: - ~CompositorFrameSinkSupport (non-viz: UI, viz: Compositor) - CompositorFrameSinkSupport::DidDeleteSharedBitmap (non-viz: UI, viz: Compositor) - RenderWidgetHostImpl::Destroy (non-viz: UI, viz: Compositor) - RenderWidgetHostImpl::DidDeleteSharedBitmap (non-viz: UI, viz: Compositor) AllocatedBitmapCount() is dead. FreeSharedMemoryFromMap() is dead. ChildAllocatedSharedBitmapForTest() is dead. BitmapData is thread-safe ref counted. It is returned by GetSharedBitmapFromId() and stored in DisplayResourceProvider, which is only used on (non-viz: UI, viz: Compositor) threads. So the BitmapData will be destroyed on those threads. The |lock_| was added in 82b5c2391ca0b3487394a2a15dc9eb97ea977c93 which claims bitmaps can be queried or deleted from the FILE and IO threads. This was when we had RenderMessageFilter::OnDeletedSharedBitmap() to report SharedBitmapIds to the browser. Now they go through CompositorFrameSink mojom to the UI thread. Also change BitmapData from RefCountedThreadSafe to RefCounted, since they are created, used, and destroyed by the DisplayResourceProvider which lives on one thread. Update the comment description of the class, as it is very out of date now, and ServerSharedBitmapManager is only used to find existing SharedBitmapIds, not to allocate them. R=piman@chromium.org Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I360e7868edf6f79990c56918a78321440fd3ee36 Reviewed-on: https://chromium-review.googlesource.com/1077671 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#563248} [modify] https://crrev.com/eef1642efc2494c74ae177de5d858e0ddc3e72f2/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/eef1642efc2494c74ae177de5d858e0ddc3e72f2/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/eef1642efc2494c74ae177de5d858e0ddc3e72f2/content/browser/browser_main_loop.cc
,
May 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e85c440e400d622c506c40fbee7a358e88fb42f5 commit e85c440e400d622c506c40fbee7a358e88fb42f5 Author: danakj <danakj@chromium.org> Date: Thu May 31 15:44:00 2018 Revert "viz: Remove thread-safety from ServerSharedBitmapManager" This reverts commit eef1642efc2494c74ae177de5d858e0ddc3e72f2. Reason for revert: Compile failure. Original change's description: > viz: Remove thread-safety from ServerSharedBitmapManager > > Auditing ServerSharedBitmapManager thread usage: > > GetSharedBitmapFromId() called by: > - DisplayResourceProvider::LockForRead > - GLRenderer, SkiaRenderer, SoftwareRenderer (non-viz: UI, viz: > Compositor) > > ChildAllocatedSharedBitmap() called by: > - CompositorFrameSinkSupport::DidAllocateSharedBitmap (non-viz: UI, > viz: Compositor) > - RenderWidgetHostImpl::DidAllocateSharedBitmap (non-viz: UI, viz: > Compositor) > > ChildDeletedSharedBitmap() called by: > - ~CompositorFrameSinkSupport (non-viz: UI, viz: Compositor) > - CompositorFrameSinkSupport::DidDeleteSharedBitmap (non-viz: UI, > viz: Compositor) > - RenderWidgetHostImpl::Destroy (non-viz: UI, viz: Compositor) > - RenderWidgetHostImpl::DidDeleteSharedBitmap (non-viz: UI, viz: > Compositor) > > AllocatedBitmapCount() is dead. > FreeSharedMemoryFromMap() is dead. > ChildAllocatedSharedBitmapForTest() is dead. > > BitmapData is thread-safe ref counted. It is returned by > GetSharedBitmapFromId() and stored in DisplayResourceProvider, which > is only used on (non-viz: UI, viz: Compositor) threads. So the > BitmapData will be destroyed on those threads. > > The |lock_| was added in 82b5c2391ca0b3487394a2a15dc9eb97ea977c93 which > claims bitmaps can be queried or deleted from the FILE and IO threads. > This was when we had RenderMessageFilter::OnDeletedSharedBitmap() to > report SharedBitmapIds to the browser. Now they go through > CompositorFrameSink mojom to the UI thread. > > Also change BitmapData from RefCountedThreadSafe to RefCounted, since > they are created, used, and destroyed by the DisplayResourceProvider > which lives on one thread. > > Update the comment description of the class, as it is very out of date > now, and ServerSharedBitmapManager is only used to find existing > SharedBitmapIds, not to allocate them. > > R=piman@chromium.org > > Bug: 730660 > Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel > Change-Id: I360e7868edf6f79990c56918a78321440fd3ee36 > Reviewed-on: https://chromium-review.googlesource.com/1077671 > Commit-Queue: danakj <danakj@chromium.org> > Reviewed-by: Antoine Labour <piman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#563248} TBR=danakj@chromium.org,piman@chromium.org Change-Id: I2dd3f897ca0fb1ef78dea1c36b6debb84ba8d99f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Reviewed-on: https://chromium-review.googlesource.com/1079737 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#563251} [modify] https://crrev.com/e85c440e400d622c506c40fbee7a358e88fb42f5/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/e85c440e400d622c506c40fbee7a358e88fb42f5/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/e85c440e400d622c506c40fbee7a358e88fb42f5/content/browser/browser_main_loop.cc
,
May 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cc330d05185e97c68f6c717e43b5f126c341aab6 commit cc330d05185e97c68f6c717e43b5f126c341aab6 Author: danakj <danakj@chromium.org> Date: Thu May 31 19:27:44 2018 Reland "viz: Remove thread-safety from ServerSharedBitmapManager" This is a reland of eef1642efc2494c74ae177de5d858e0ddc3e72f2 TBR=piman Original change's description: > viz: Remove thread-safety from ServerSharedBitmapManager > > Auditing ServerSharedBitmapManager thread usage: > > GetSharedBitmapFromId() called by: > - DisplayResourceProvider::LockForRead > - GLRenderer, SkiaRenderer, SoftwareRenderer (non-viz: UI, viz: > Compositor) > > ChildAllocatedSharedBitmap() called by: > - CompositorFrameSinkSupport::DidAllocateSharedBitmap (non-viz: UI, > viz: Compositor) > - RenderWidgetHostImpl::DidAllocateSharedBitmap (non-viz: UI, viz: > Compositor) > > ChildDeletedSharedBitmap() called by: > - ~CompositorFrameSinkSupport (non-viz: UI, viz: Compositor) > - CompositorFrameSinkSupport::DidDeleteSharedBitmap (non-viz: UI, > viz: Compositor) > - RenderWidgetHostImpl::Destroy (non-viz: UI, viz: Compositor) > - RenderWidgetHostImpl::DidDeleteSharedBitmap (non-viz: UI, viz: > Compositor) > > AllocatedBitmapCount() is dead. > FreeSharedMemoryFromMap() is dead. > ChildAllocatedSharedBitmapForTest() is dead. > > BitmapData is thread-safe ref counted. It is returned by > GetSharedBitmapFromId() and stored in DisplayResourceProvider, which > is only used on (non-viz: UI, viz: Compositor) threads. So the > BitmapData will be destroyed on those threads. > > The |lock_| was added in 82b5c2391ca0b3487394a2a15dc9eb97ea977c93 which > claims bitmaps can be queried or deleted from the FILE and IO threads. > This was when we had RenderMessageFilter::OnDeletedSharedBitmap() to > report SharedBitmapIds to the browser. Now they go through > CompositorFrameSink mojom to the UI thread. > > Also change BitmapData from RefCountedThreadSafe to RefCounted, since > they are created, used, and destroyed by the DisplayResourceProvider > which lives on one thread. > > Update the comment description of the class, as it is very out of date > now, and ServerSharedBitmapManager is only used to find existing > SharedBitmapIds, not to allocate them. > > R=piman@chromium.org > > Bug: 730660 > Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel > Change-Id: I360e7868edf6f79990c56918a78321440fd3ee36 > Reviewed-on: https://chromium-review.googlesource.com/1077671 > Commit-Queue: danakj <danakj@chromium.org> > Reviewed-by: Antoine Labour <piman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#563248} Bug: 730660 Change-Id: I665f323c52db6cd7957e62507e74b8af0d2e0628 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Reviewed-on: https://chromium-review.googlesource.com/1079738 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#563346} [modify] https://crrev.com/cc330d05185e97c68f6c717e43b5f126c341aab6/components/viz/service/display_embedder/server_shared_bitmap_manager.cc [modify] https://crrev.com/cc330d05185e97c68f6c717e43b5f126c341aab6/components/viz/service/display_embedder/server_shared_bitmap_manager.h [modify] https://crrev.com/cc330d05185e97c68f6c717e43b5f126c341aab6/content/browser/browser_main_loop.cc
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1529f944ce4c3c2895b2826d4e8be9249f257694 commit 1529f944ce4c3c2895b2826d4e8be9249f257694 Author: danakj <danakj@chromium.org> Date: Fri Jun 01 00:02:37 2018 viz: Remove thread-safety from TestSharedBitmapManager Similar to https://chromium-review.googlesource.com/c/chromium/src/+/1077671 the TestSharedBitmapManager is not used from multiple threads. Also adds a SequenceChecker to the class. TestLayerTreeFrameSink then needs to make the TestSharedBitmapManager and destroy it on the thread where it will be used. R=piman@chromium.org NOTRY=true Bug: 730660 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I516942cb8331444953b1837e31c5be974203e118 Reviewed-on: https://chromium-review.googlesource.com/1079148 Commit-Queue: danakj <danakj@chromium.org> Reviewed-by: Antoine Labour <piman@chromium.org> Cr-Commit-Position: refs/heads/master@{#563445} [modify] https://crrev.com/1529f944ce4c3c2895b2826d4e8be9249f257694/components/viz/test/test_layer_tree_frame_sink.cc [modify] https://crrev.com/1529f944ce4c3c2895b2826d4e8be9249f257694/components/viz/test/test_layer_tree_frame_sink.h [modify] https://crrev.com/1529f944ce4c3c2895b2826d4e8be9249f257694/components/viz/test/test_shared_bitmap_manager.cc [modify] https://crrev.com/1529f944ce4c3c2895b2826d4e8be9249f257694/components/viz/test/test_shared_bitmap_manager.h
,
Jun 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f77f6b8dba2776e23111c84c5d9333dbb03039fe commit f77f6b8dba2776e23111c84c5d9333dbb03039fe Author: kylechar <kylechar@chromium.org> Date: Wed Jun 13 20:29:11 2018 Fix UseSurfaceLayerForVideo GPU crash handling. When UseSurfaceLayerForVideo and VizDisplayCompositors are both enabled with software compositing, VideoFrameSubmitter doesn't detect and recover from GPU process crashes. Add a connection error handler on the mojom::CompositorFrameSinkPtr to handle this case. Bug: 730660 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie364610bc61de3cdb3a18ce62f23e0fa217219df Reviewed-on: https://chromium-review.googlesource.com/1099475 Commit-Queue: kylechar <kylechar@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#566971} [modify] https://crrev.com/f77f6b8dba2776e23111c84c5d9333dbb03039fe/third_party/blink/renderer/platform/graphics/video_frame_submitter.cc
,
Jul 27
=> kylechar to triage the remaining 2 blockers
,
Aug 14
,
Aug 14
This is all done.
Showing comments 26 - 125
of 125
Older ›
|
||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||
