mash: System tray bubble does not paint due to accelerated layer usage |
||||||
Issue descriptionRepro: * Build mash:all on Linux (both oxygen and non-oxygen builds will repro) * out/Default/mojo_runner mojo:mash_session * Click on the system tray in the lower right You'll get a bubble window with rounded corners and a shadow, but no contents. If you add logging to a view like DefaultDateView and hover the mouse over where the date should be in the bubble, you'll see it respond to hover events and try to re-paint itself -- the views are there. The views become visible if you don't use accelerated layers, by removing SetPaintToLayer(true) and similar code in the TrayBubbleView() constructor. See this patch: https://codereview.chromium.org/1837093003 Rob thinks the views implementation for mus is not doing the right thing with an accelerated layer. "It needs to get its own backing surface and the CompositorFrame for the window has to reference the right stuff." This might be because ash_sysui is trying to use multiple hardware layers. (I've also noticed that Chrome in mus doesn't paint the omnibox, and I know there are accelerated layers in that part of the UI. I wonder if it is the same problem.) To Rob for triage.
,
Mar 31 2016
Picking this up now.
,
Mar 31 2016
I'm a bit confused about the setup here. The SysTray Bubble is a mus::Window. It expects to have a separate ui::Compositor, I think. I'm not sure if that's what's happening. A SurfaceContextFactory is tied to a single mus::Window and yet we seem to have a context factory set as a part of the aura::Env. https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/mus/native_widget_mus.cc&sq=package:chromium&type=cs&rcl=1459423839&l=268
,
Apr 1 2016
The CompositorFrames do ship an extra TileDrawQuad when SetPaintToLayer(true) so something is making its way into Mus. I am now investigating if this is a GPU issue. It's possible that this is an image upload or sync point issue.
,
Apr 4 2016
Some background from the ash and views side: TrayBubbleView is-a BubbleDelegateView which creates a widget via BubbleDelegateView::CreateBubble -> CreateWidget. AFAIK each Widget in an app (in this case ash_sysui) is backed by a mus::Window.
,
Apr 6 2016
I think I have a fix: https://codereview.chromium.org/1864953002/
,
Apr 6 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/336b3700484b2fba745b756f22ea85db854e0c10 commit 336b3700484b2fba745b756f22ea85db854e0c10 Author: sadrul <sadrul@chromium.org> Date: Wed Apr 06 15:02:24 2016 ash/mash: Fix painting of status-tray bubble. Change NativeWidgetMus::GetLayer() to return the correct ui::Layer, to make sure that the layer-tree for the Views in a Widget is added a child to the Layer associated with the Widget. BUG= 598914 Review URL: https://codereview.chromium.org/1864953002 Cr-Commit-Position: refs/heads/master@{#385463} [modify] https://crrev.com/336b3700484b2fba745b756f22ea85db854e0c10/ui/views/mus/native_widget_mus.cc [modify] https://crrev.com/336b3700484b2fba745b756f22ea85db854e0c10/ui/views/mus/native_widget_mus_unittest.cc
,
Apr 9 2016
Seems fixed?
,
Apr 11 2016
Yep, fixed. Closing.
,
Feb 26 2018
,
Feb 26 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by rjkroege@chromium.org
, Mar 30 2016Components: -MUS MUS>Phase>1
Labels: mustash1