| Issue 53165: | Resizing looks broken when accelerated drawing path is used | |
| 7 people starred this issue and may be notified of changes. | Back to list |
Restricted
Sign in to add a comment
|
What steps will reproduce the problem? 1. Start with --enable-accelerated-compositing 2. Open poster circle demo 3. Open task manager 4. Resize window like crazy. What is the expected result? Mostly constant memory usage, no drawing artifacts. What happens instead? Memory usage goes up and to the right, drawing artifacts are visible while resizing happens. (This is not a regression caused by the glview cl for a change :-P)
Aug 24, 2010
#1
pinkerton@chromium.org
Labels:
-Pri-2 Pri-1
Aug 24, 2010
(No comment was entered for this change.)
Status:
Assigned
Aug 24, 2010
Theory about the visual brokenness: when the window is resized, 1. a new IOSurface is allocated 2. the rwhv is notified of the new surface 3. the IOSurface is drawn into for the first time by the gpu process (or the plugin process) If the rwhv paints after 2, it will show uninitialized memory.
Aug 24, 2010
Having a (lock-protected) boolean suppressPainting that's set to true in AcceleratedSurfaceSetIOSurface and to false in AcceleratedSurfaceBuffersSwapped gets rid of the garbage. Of course, this means that sometimes nothing's there to draw during resizing (in the interval between us getting the new surface and the new surface getting painted), and the window becomes transparent during that time :-P But at least the cause for the garbage is identified. Still stumped about the memory leak. Doesn't help that the IOSurface stuff isn't very documented.
Aug 24, 2010
Great. Thanks for tracking down the root cause of the garbage. We should probably try to figure out how to preserve the IOSurface's current contents when allocating the new one and discarding the old one. Does it look like we're properly CFRelease'ing the IOSurface handles in both the GPU and browser processes during the resizing operation?
Aug 24, 2010
We're releasing in both processes at first glance (I'm a bit surprised it's required in the browser process; doesn't mesh with the "create rule" naming convention – maybe we should retain in the browser process. but that won't help with leaks). I didn't check where/how retain counts change; will do that next.
Aug 24, 2010
I printed retain counts for the iosurfaces in AcceleratedSurfaceContainerMac::ReleaseIOSurface() / AcceleratedSurfaceContainerMac::SetSizeAndIOSurface() and in AcceleratedSurface::SetSurfaceSize(). They look sane. AcceleratedSurface has this comment: // The FBO and texture objects will be destroyed when the OpenGL context, // and any other contexts sharing resources with it, is. We don't want to // make the context current one last time here just in order to delete // these objects. However, I checked that only one texture object is allocated and that it is reused. I uncommented the call to CGLTexImageIOSurface2D() in the gpu process; that didn't change anything.
Aug 24, 2010
$ vmmap -d 10 76141 Virtual Memory Map of process 76141 (Chromium Helper) Output report format: 2.2 -- 32-bit process ========= Regions in 1st snapshot not in 2nd ========== ==== Non-writable regions for process 76141 MALLOC (admin) 083db000-083dc000 [ 4K] r--/rwx SM=PRV ==== Writable regions for process 76141 __OBJC 03945000-03961000 [ 112K] rw-/rwx SM=PRV /Volumes/MacintoshHD2/src/chrome-git/src/xcodebuild/Debug/Chromium.app/Contents/Versions/7.0.505.0/Chromium Framework.framework/Chromium Framework MALLOC (admin) 083de000-083df000 [ 4K] rw-/rwx SM=PRV MALLOC (admin) 083e1000-083e7000 [ 24K] rw-/rwx SM=PRV MALLOC_TINY 08400000-08500000 [ 1024K] rw-/rwx SM=COW DefaultMallocZone_0x83c9000 MALLOC_TINY 08600000-08700000 [ 1024K] rw-/rwx SM=PRV DispatchContinuations_0x83de000 MALLOC (admin) 0870b000-0870c000 [ 4K] rw-/rwx SM=PRV MALLOC_TINY (freed) 13900000-13a00000 [ 1024K] rw-/rwx SM=PRV DispatchContinuations_0x83de000 MALLOC_TINY (freed) 13e00000-13f00000 [ 1024K] rw-/rwx SM=PRV DispatchContinuations_0x83de000 IOKit 1505d000-16879000 [ 24.1M] rw-/rw- SM=ALI IOKit 16b79000-16c79000 [ 1024K] rw-/rw- SM=SHM MALLOC_TINY (freed) 16e00000-16f00000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 MALLOC_LARGE 17489000-175ad000 [ 1168K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 MALLOC_LARGE (freed) 175ad000-176c2000 [ 1108K] rw-/rwx SM=PRV IOKit 176c2000-17725000 [ 396K] rw-/rw- SM=SHM MALLOC_LARGE (freed) 17825000-1787f000 [ 360K] rw-/rwx SM=PRV IOKit 17a35000-18254000 [ 8316K] rw-/rw- SM=SHM IOKit 18b00000-19000000 [ 5120K] rw-/rw- SM=SHM MALLOC_SMALL 19000000-19800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 MALLOC_SMALL 1a000000-1a800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 1a800000-1aa00000 [ 2048K] rw-/rw- SM=SHM IOKit 1ab00000-1ac00000 [ 1024K] rw-/rw- SM=SHM ========= Regions in 2nd snapshot not in 1st ========== ==== Non-writable regions for process 76141 MALLOC (admin) 083db000-083dc000 [ 4K] r--/rwx SM=COW ==== Writable regions for process 76141 __OBJC 03945000-03961000 [ 112K] rw-/rwx SM=COW /Volumes/MacintoshHD2/src/chrome-git/src/xcodebuild/Debug/Chromium.app/Contents/Versions/7.0.505.0/Chromium Framework.framework/Chromium Framework MALLOC (admin) 083de000-083df000 [ 4K] rw-/rwx SM=COW MALLOC (admin) 083e1000-083e7000 [ 24K] rw-/rwx SM=COW MALLOC_TINY 08400000-08411000 [ 68K] rw-/rwx SM=COW DefaultMallocZone_0x83c9000 MALLOC_TINY (freed) 08411000-08500000 [ 956K] rw-/rwx SM=COW DefaultMallocZone_0x83c9000 MALLOC_TINY 08600000-08700000 [ 1024K] rw-/rwx SM=COW DispatchContinuations_0x83de000 MALLOC (admin) 0870b000-0870c000 [ 4K] rw-/rwx SM=COW IOKit 087e0000-087f2000 [ 72K] rw-/rw- SM=ALI MALLOC_TINY (freed) 13900000-13a00000 [ 1024K] rw-/rwx SM=COW DispatchContinuations_0x83de000 IOKit 13a00000-13b00000 [ 1024K] rw-/rw- SM=SHM MALLOC_TINY (freed) 13e00000-13f00000 [ 1024K] rw-/rwx SM=COW DispatchContinuations_0x83de000 IOKit 1505d000-1555d000 [ 5120K] rw-/rw- SM=SHM IOKit 155f5000-157f5000 [ 2048K] rw-/rw- SM=SHM IOKit 157f5000-15b55000 [ 3456K] rw-/rw- SM=ALI MALLOC_TINY (freed) 15c00000-15d00000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 15d00000-15f25000 [ 2196K] rw-/rw- SM=ALI IOKit 15f87000-16087000 [ 1024K] rw-/rw- SM=SHM IOKit 1609b000-1619b000 [ 1024K] rw-/rw- SM=SHM MALLOC_TINY (freed) 16200000-16300000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 16300000-16800000 [ 5120K] rw-/rw- SM=SHM IOKit 16a79000-16c79000 [ 2048K] rw-/rw- SM=SHM MALLOC_TINY 16e00000-16f00000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 16f00000-17300000 [ 4096K] rw-/rw- SM=SHM IOKit 175ad000-176ad000 [ 1024K] rw-/rw- SM=SHM IOKit 176c2000-17825000 [ 1420K] rw-/rw- SM=SHM IOKit 179c6000-17bc6000 [ 2048K] rw-/rw- SM=SHM IOKit 17bd5000-17dd5000 [ 2048K] rw-/rw- SM=SHM IOKit 17df7000-17ff7000 [ 2048K] rw-/rw- SM=SHM MALLOC_LARGE (freed) 17ff7000-181e1000 [ 1960K] rw-/rwx SM=PRV IOKit 181e5000-182e5000 [ 1024K] rw-/rw- SM=SHM IOKit 18700000-18800000 [ 1024K] rw-/rw- SM=SHM IOKit 18900000-19000000 [ 7168K] rw-/rw- SM=SHM MALLOC_SMALL (freed) 19000000-19800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 MALLOC_SMALL (freed) 1a000000-1a800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 1a800000-1ac00000 [ 4096K] rw-/rw- SM=SHM IOKit 1ac00000-1ae25000 [ 2196K] rw-/rw- SM=ALI IOKit 1af72000-1b0ad000 [ 1260K] rw-/rw- SM=ALI MALLOC_TINY (freed) 1b100000-1b200000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 1b200000-1b34d000 [ 1332K] rw-/rw- SM=ALI IOKit 1b425000-1b991000 [ 5552K] rw-/rw- SM=ALI IOKit 1ba82000-1bb9b000 [ 1124K] rw-/rw- SM=ALI IOKit 1bc3e000-1c43e000 [ 8192K] rw-/rw- SM=SHM IOKit 1c44d000-1cb04000 [ 6876K] rw-/rw- SM=ALI IOKit 1cb04000-1ce91000 [ 3636K] rw-/rw- SM=SHM IOKit 1d37c000-1d47c000 [ 1024K] rw-/rw- SM=SHM IOKit 1d6dd000-1d7dd000 [ 1024K] rw-/rw- SM=SHM MALLOC_LARGE (freed) 1d878000-1daf3000 [ 2540K] rw-/rwx SM=PRV IOKit 1daf3000-1e1aa000 [ 6876K] rw-/rw- SM=ALI MALLOC_LARGE (freed) 1e495000-1e67f000 [ 1960K] rw-/rwx SM=PRV IOKit 1e67f000-1ed36000 [ 6876K] rw-/rw- SM=ALI MALLOC_SMALL (freed) 1f000000-1f800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 MALLOC_LARGE (freed) 1f800000-1fa7b000 [ 2540K] rw-/rwx SM=PRV IOKit 1fa7b000-1fe08000 [ 3636K] rw-/rw- SM=ALI MALLOC_SMALL 20000000-20800000 [ 8192K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 20800000-20b8d000 [ 3636K] rw-/rw- SM=ALI IOKit 20e5d000-21a03000 [ 11.6M] rw-/rw- SM=ALI MALLOC_LARGE (freed) 21a03000-21d78000 [ 3540K] rw-/rwx SM=PRV MALLOC_LARGE (freed) 2233e000-226b3000 [ 3540K] rw-/rwx SM=PRV MALLOC_LARGE (freed) 22d84000-23054000 [ 2880K] rw-/rwx SM=PRV IOKit 23054000-23887000 [ 8396K] rw-/rw- SM=ALI MALLOC_LARGE (reused) 23978000-23c48000 [ 2880K] rw-/rwx SM=PRV IOKit 23c48000-24c55000 [ 16.1M] rw-/rw- SM=ALI IOKit 27380000-27549000 [ 1828K] rw-/rw- SM=ALI MALLOC_TINY (freed) 29300000-29400000 [ 1024K] rw-/rwx SM=PRV DefaultMallocZone_0x83c9000 IOKit 29cee000-29eb7000 [ 1828K] rw-/rw- SM=ALI ==== Legend SM=sharing mode: COW=copy_on_write PRV=private NUL=empty ALI=aliased SHM=shared ZER=zero_filled S/A=shared_alias
Aug 24, 2010
It still happens if I uncomment IOSurface creation in both processes and return early from GpuCommandBufferStub::OnSetWindowSize() and GPUProcessor::SetWindowSizeForIOSurface(). Since this is leaking shared memory, maybe it's leaking data that's being sent from the renderer? I checked that this doesn't happen on windows; haven't checked linux yet.
Aug 25, 2010
That's a great find. It's certainly possible that not all of the old rendering paths are being properly disabled when the compositor is active, and we're still allocating (and not freeing) TransportDIB backing store for the RWHV or something similar. CC'ing vangelis.
Cc:
vange...@chromium.org
Aug 25, 2010
After some more investigation, the gpu process might leak a bit faster when iosurfaces are enabled. Another way how the repainting bug manifests itself: During resizing, the bottom right edges of the window might temporarily become transparent (the gl-hosting view is resized immediately, but the gl surface needs a while to catch up). If the fix is to send the resize notification only when the surface has been painted to, nothing needs to be done to fix this (well, maybe the rwhvmac needs to be told to not paint the backing store when compositing is active). If the fix is to keep up to two IOSurfaces around in the browser, then gl needs to draw some padding.
Aug 25, 2010
This check-in: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host.cc?r1=57359&r2=57358 should have eliminated unnecessary dib allocations.
Cc:
nd...@chromium.org
Aug 25, 2010
That's in the browser. The GPU process is leaking; I was thinking maybe it leaks the image data the renderer sends to it.
Aug 30, 2010
Ran ioclasscount before and after resizing a lot and looked at the diff --- ioclasscount0.txt 2010-08-30 18:13:43.000000000 -0700 +++ ioclasscount1.txt 2010-08-30 18:14:41.000000000 -0700 @@ -399,7 +399,7 @@ IOBootFramebuffer = 0 IOBootNDRV = 0 IOBreaker = 0 -IOBufferMemoryDescriptor = 1319 +IOBufferMemoryDescriptor = 1798 IOCatalogue = 1 IOCDBlockStorageDevice = 1 IOCDBlockStorageDriver = 1 @@ -525,7 +525,7 @@ IOFWWriteCommand = 0 IOFWWriteQuadCommand = 0 IOGatedOutputQueue = 1 -IOGeneralMemoryDescriptor = 431 +IOGeneralMemoryDescriptor = 449 IOGraphicsDevice = 1 IOGraphicsWorkLoop = 2 IOGUIDPartitionScheme = 2 @@ -594,7 +594,7 @@ IOMediaBSDClient = 6 IOMemoryCursor = 2 IOMemoryDescriptor = 2 -IOMemoryMap = 2270 +IOMemoryMap = 2806 IOModemSerialStreamSync = 1 IOMultiMemoryDescriptor = 0 IONaturalMemoryCursor = 1 @@ -725,7 +725,7 @@ NV2DContext = 2 nvChannel = 2 nvChannelManager = 1 -nvContiguousPhysBlockList = 153 +nvContiguousPhysBlockList = 158 nvCudaContext = 0 nvCurieChannelManager = 0 nvCurieDisplayManager = 0 @@ -754,7 +754,7 @@ NVKernel = 1 NVMemory = 1 NVOCDContext = 0 -nvPhysBlockList = 60 +nvPhysBlockList = 74 NVPipelineProfile = 1 nvPushBuffer = 8 nvRingBuffer = 7 @@ -772,11 +772,11 @@ nvTeslaSurface = 20 nvTimerAction = 4 nvTimerManager = 1 -OSArray = 6204 +OSArray = 6680 OSBoolean = 2 OSCollection = 4 OSCollectionIterator = 34 -OSData = 53695 +OSData = 54192 OSDictionary = 16048 OSIterator = 3 OSKext = 115 @@ -786,7 +786,7 @@ OSOrderedSet = 36 OSSerialize = 1 OSSerializer = 7 -OSSet = 1496 +OSSet = 1972 OSString = 9703 OSSymbol = 3963 PMHaltWorker = 0 ~400 IOBufferMemoryDescriptor, ~500 IOMemoryMap ~400 OSArray ~500 OSData ~500 OSSet
Aug 31, 2010
Is the above ioclasscount output with all of the code paths enabled, or with IOSurface allocation/deallocation commented out? If it's with all of the code paths enabled, maybe we could try gathering the same information without allocating IOSurfaces at all (breaking rendering) and seeing if the same leaks are present. We could also try doing the same with the compositor disabled. It seems almost certain to me that we are leaking TransportDIBs when the compositor is on.
Aug 31, 2010
That was with all code paths enabled. Good idea.
Sep 1, 2010
Attached is the output of the following dtrace script:
#!/usr/sbin/dtrace -s
fbt::mach_vm_map:entry
/ arg2 > 1000*1000 && pid == $target /
{
printf("Size: %s %d\n",
execname,
arg2
);
ustack();
stack();
}
Called as follows:
sudo dtrace -s vmmap.d -p 70791
(70791 was the pid of the GPU process).
Looks like most allocations are done by glTexSubImage2D() calls or IOSurfaceCreate() calls. (Didn't check if any of those get unmapped again yet.)
We probably want to do some kind of resize-ack scheme, like the browser and renderer do, to keep memory traffic under control here.
Sep 3, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=58504
------------------------------------------------------------------------
r58504 | thakis@chromium.org | 2010-09-03 10:56:03 -0700 (Fri, 03 Sep 2010) | 10 lines
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=58504&r2=58503
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=58504&r2=58503
Mac: Make resizing the window larger nicer when compositor is active
We need to fill the part of the RWHVMac not covered by the compositor subview with white.
Resizing smaller is still a bit jumpy. We also still paint an uninitialized IOSurface every now and then.
BUG=53165
TEST=Enable compositor, make window larger. Right bottom part of window shouldn't be transparent.
Review URL: http://codereview.chromium.org/3319004
------------------------------------------------------------------------
Sep 3, 2010
I can no longer see the memory leak. I installed the OS X graphics update over autoupdate recently. Weird. (I noticed that I can no longer see the leak in chrome after I wrote two small programs exchanging IOSurfaces to have a minimal repro.)
Sep 8, 2010
What's left to do here is to not draw IOSurfaces that haven't been painted to yet. Approaches for that are either only sending IOSurfaces from the GPU process after their contents are valid, or keeping two IOSurfaces (last painted IOSurface, current IOSurface – most of the time these two will be the same object, but not during resizing) and only drawing the last painted surface.
Sep 10, 2010
(No comment was entered for this change.)
Labels:
-Mstone-7 Mstone-8
Sep 29, 2010
rohitbm informed me that "pop out" on hulu also triggers this for plugins. I guess that makes this m7?
Summary:
Resizing looks broken when accelerated drawing path is used
Sep 29, 2010
It would definitely be nice to get for M7, but I don't think it's critical; a brief flash of garbage doesn't cause any serious usability issues.
Oct 2, 2010
I tried the repro steps and after some scary graphic corruption, the Chrome window goes white and Chrome becomes unresponsive (have to force quit). This is reproducible. The morphing power cube demo results in a dead tab "Snap!". These bugs look serious, but my Chrome version may not have the latest fix. I'm on 7.0.536.2 dev, OS X 10.6.4 with graphics update, Geforce 9400M. Jean
Oct 2, 2010
comment 25: The white window is issue 55754. It's fixed, but the fix is not in the current dev channel. The next dev channel should have the fix. Can you give me a link to that power cube demo?
Oct 11, 2010
Changing milestone from Mstone8 to Mstone-9
Labels:
Mstone-9
Oct 15, 2010
Link to the morphing cubes demo: http://webkit.org/blog-files/3d-transforms/morphing-cubes.html Chrome 8.0.552.0 dev shows scary artifacts when you resize the window.
Oct 28, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=64317
------------------------------------------------------------------------
r64317 | thakis@chromium.org | Thu Oct 28 14:39:14 PDT 2010
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gpu_messages_internal.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gpu_process_host.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/test/test_render_view_host.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/gpu/gpu_command_buffer_stub.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gpu_process_host.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/plugin_messages_internal.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/test/test_render_view_host.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_mac.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_mac.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/app/surface/accelerated_surface_mac.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/app/surface/accelerated_surface_mac.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gpu_processor.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/webplugin_proxy.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/render_messages_internal.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/webplugin_proxy.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/webplugin_delegate_proxy.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/webplugin_accelerated_surface_proxy_mac.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/webplugin_delegate_proxy.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gpu_processor_mac.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view.h?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/command_buffer_stub.cc?r1=64317&r2=64316&pathrev=64317
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=64317&r2=64316&pathrev=64317
Let every "accelerated IO surface swapped" message have an identifier of the surface.
Currently, this is only used to DCHECK a currently implicit invariant, but I want to use this to let every surface container only remember its last painted-to surface, and not its last created surface.
No behavior change.
BUG=53165
TEST=none
Review URL: http://codereview.chromium.org/4142004
------------------------------------------------------------------------
Nov 1, 2010
Issue 61483 has been merged into this issue.
Cc:
kr...@chromium.org rohi...@chromium.org tha...@chromium.org
Nov 1, 2010
Issue 59801 has been merged into this issue.
Nov 1, 2010
http://codereview.chromium.org/4101002/show
Nov 1, 2010
(No comment was entered for this change.)
Labels:
-Feature-GPU Feature-GPU-Compositing
Nov 1, 2010
Issue 59805 has been merged into this issue.
Nov 1, 2010
(No comment was entered for this change.)
Status:
Started
Nov 2, 2010
(No comment was entered for this change.)
Cc:
bac...@chromium.org
Nov 5, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=65220
------------------------------------------------------------------------
r65220 | thakis@chromium.org | Fri Nov 05 11:07:26 PDT 2010
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/app/surface/io_surface_support_mac.cc?r1=65220&r2=65219&pathrev=65220
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.cc?r1=65220&r2=65219&pathrev=65220
M http://src.chromium.org/viewvc/chrome/trunk/src/app/surface/io_surface_support_mac.h?r1=65220&r2=65219&pathrev=65220
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_mac.cc?r1=65220&r2=65219&pathrev=65220
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_mac.h?r1=65220&r2=65219&pathrev=65220
Mac/gpu: Don't show uninitialized surfaces while resizing plugins / composited tabs.
BUG=53165
TEST=Go to http://webkit.org/blog/386/3d-transforms/. Resize window. Watch a youtube video click the "make bigger" button. No garbage should appear. There are still some funky artifacts at the top/right border during resizing caused by clamping the texture instead of filling with white, and sometimes (rarely) the tab flashes black/white but I'd like to tackle that in follow-up CLs. This is already much better than what's in the tree currently.
Review URL: http://codereview.chromium.org/4101002
------------------------------------------------------------------------
Nov 5, 2010
D'oh, forgot to update the CL description before submitting. There are no artifacts at the top/right border; stuart made me fix this in that CL. The only thing left here is to sync-wait for 50ms or so during resizing to make the tearing at the border less visible.
Nov 8, 2010
Verified label updated by AutoAllocator, contact AmolK or KrisR for details
Labels:
Verifier-Rohitbm
Nov 15, 2010
9.0.583.0 (Official Build 66097)
Status:
Verified
Oct 12, 2012
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels:
Restrict-AddIssueComment-Commit
Blocking: -chromium:57645 chromium:57645
Mar 10, 2013
(No comment was entered for this change.)
Labels:
-Area-UI -Mstone-9 -Feature-GPU-Compositing M-9 Cr-Internals-GPU-Compositing Cr-UI
Mar 13, 2013
(No comment was entered for this change.)
Labels:
-Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
(No comment was entered for this change.)
Labels:
-Cr-Internals-GPU-Compositing Cr-Internals-Compositing
|
||||||||||
| ► Sign in to add a comment | |||||||||||
