New issue
Advanced search Search tips

Issue 645266 link

Starred by 2 users
Status: Fixed
Owner: ----
Closed: Apr 2018
Cc:
ellyjo...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug

Blocking:
issue 630357



Sign in to add a comment

Harmony [Mac] - Dialogs repaint when mouse in or out of popups and buttons

Project Member Reported by shrike@chromium.org, Sep 8 2016 
<b>Version: <Kenneth, what is the frequency?></b>
<b>OS: <please tell me it's not XP></b>

What steps will reproduce the problem?
(1) Enable MacViews
(2) In Quartz Debug, enable Flash Screen Updates
(3) In Chrome, navigate to android.com and click the lock icon in the Omnibox
(4) Mouse over the popup controls

What is the expected output?
Controls should fully repaint (or not) as you mouse in and out of them, but no where else should.

What do you see instead?
The controls repaint, but so does the entire dialog. It looks like three full repaints on each boundary crossing.

Same happens when you mouse in and out of the Primary and Secondary buttons in the bookmarks dialog.

Likely also occurs on Windows and Linux.
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 15 2016 

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

commit 9469d57224252e71f21394f17a30929ec3fd102e
Author: ellyjones <ellyjones@chromium.org>
Date: Thu Sep 15 10:20:35 2016

combobox: don't animate state changes in TransparentButton

TransparentButton has state-change animations enabled despite being invisible,
which causes a bunch of spurious repaints of the combobox on mouse enter/exit.

BUG= 645266 

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

[modify] https://crrev.com/9469d57224252e71f21394f17a30929ec3fd102e/ui/views/controls/combobox/combobox.cc

Comment 2 by shrike@chromium.org, Oct 1 2016

Labels: Proj-HarmonyControls

Comment 3 by pkasting@chromium.org, Jan 25 2017 

We probably indeed do excessive repaints on other platforms, but I'm not sure how to easily debug.  Fixing things on MacViews would likely fix them everywhere.

It's not clear to me this is P2.  Seems P3, unless it's going to result in burning noticeable power on the compositor (unlikely if we're only talking about the case of mousing around dialogs).

Comment 4 by pkasting@chromium.org, Aug 2 2017

Labels: -M-55
M-55 clearly didn't happen.

I don't know how to triage MacViews in depth, so not changing owner/priority.  This hasn't been touched in a while; please retriage.

Comment 5 by ellyjo...@chromium.org, Aug 2 2017

Cc: ellyjo...@chromium.org
Labels: -Pri-2 MacViews-Cleanup Pri-3
Owner: ----
Status: Available (was: Assigned)
I just tested this again, and yep, it does. That said, this isn't user-visible at all and is difficult to avoid with the current compositor design (I think), so I'm going to punt this.

Comment 6 by gov...@chromium.org, Apr 13 2018

Labels: Proj-MacViews

Comment 7 by ellyjo...@chromium.org, Apr 17 2018

Status: Fixed (was: Available)
This bug is Fixed - MdTextButtons paint to a layer, which means they don't damage the containing dialog's layer any more when painting.
►

Sign in to add a comment