Harmony - large repaint of cookies dialog when tab focus from Close button to "x" close button |
|||||||
Issue descriptionVersion: 55.0.2861.0 OS: 10.11 What steps will reproduce the problem? (1) Navigate to https://carlosjeurissen.com/black-menu-for-google (site not important, per se, except this one does not animate its page, which means you don't get a mess of irrelevant yellow flashes from Quartz Debug) (2) Click the lock icon in the Omnibox (3) Click the cookies link in the OIB (4) With full keyboard tab-to-focus enabled, tab several times to focus the Close button at the bottom of the dialog (5) Activate Flash screen updates in Quartz Debug (6) Press the tab key What is the expected output? Quartz Debug should flash yellow over the Close button, and separately over the "x" close button in the upper right. What do you see instead? Quartz Debug flashes yellow over almost the entire dialog (the section that does not flash yellow is the narrow strip from top to bottom of the dialog just to the left of the tableview). When redrawing two controls, Views seems to redraw the union rect of the frames of those controls (which is not as efficient as it could be). But the redraw region in this case is much larger than the union of the two frames.
,
Sep 21 2016
But seems like that would mean the dialog should do a full repaint on every redraw? In this case there's a sliver along the left that doesn't get redrawn, and if I tab between other buttons in the dialog only those buttons get redrawn, not the entire dialog.
,
Oct 1 2016
,
Jan 27 2017
Given comment 1, is this MacViews-specific? Or is this an underlying cross-platform issue with excessive repainting in views? Lowering to P3 for now as this would not block shipping.
,
Feb 2 2017
Note just setting settings.renderer_settings.use_gpu_memory_buffer_resources = true; On Mac in src/ui/compositor/compositor.cc results in a lot of [179:775:0202/141658.582550:ERROR:gles2_cmd_decoder.cc(16192)] [.CompositorWorker-0x7ffe94893a00]GL ERROR :GL_INVALID_OPERATION : glCopySubTextureCHROMIUM: target should be aligned with dest target so there's more to investigate here. #c4: On non-Mac compositor_util.cc's IsGpuMemoryBufferCompositorResourcesEnabled() defaults to `false`, so I think this is Mac-specific.
,
Aug 9 2017
,
Aug 31 2017
https://chromium-review.googlesource.com/c/chromium/src/+/642210
,
Sep 6 2017
Issue 762319 has been merged into this issue.
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47862bc479eeb61ef945d3c23d1ba34c11873bfc commit 47862bc479eeb61ef945d3c23d1ba34c11873bfc Author: Trent Apted <tapted@chromium.org> Date: Thu Sep 07 02:22:40 2017 Use GPU memory buffer resources and zero copy for MacViews. This allows UI to use CoreAnimation for compositing, resulting in efficiency gains. Using CoreAnimation to composite requires using GpuMemoryBuffers, which require zero copy. This combination is enabled by default on Mac for the renderer already. This CL enables zero copy and GpuMemoryBuffers on Mac for UI. Bug: 648430 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I27852e56e93ab869d212e7c1486eb2ba320d2407 Reviewed-on: https://chromium-review.googlesource.com/642210 Commit-Queue: Trent Apted <tapted@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: ccameron chromium <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#500189} [modify] https://crrev.com/47862bc479eeb61ef945d3c23d1ba34c11873bfc/ui/compositor/compositor.cc [modify] https://crrev.com/47862bc479eeb61ef945d3c23d1ba34c11873bfc/ui/compositor/compositor_switches.cc [modify] https://crrev.com/47862bc479eeb61ef945d3c23d1ba34c11873bfc/ui/compositor/compositor_switches.h
,
Sep 7 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ccameron@chromium.org
, Sep 21 2016777 KB
777 KB View Download