New issue
Advanced search Search tips

Issue 645262 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Blocking:
issue 630357



Sign in to add a comment

Harmony [Mac] - Bookmarks dialog continuously repainted

Project Member Reported by shrike@chromium.org, Sep 8 2016

Issue description

Version: 55.0.2853.0
OS: 10.11

What steps will reproduce the problem?
(1) Enable MacViews
(2) In Quartz Debug, enable Flash Screen Updates
(3) In Chrome, click the star icon in the Omnibox

What is the expected output?
The bookmarks dialog should not show any yellow flashing

What do you see instead?
The entire dialog flashes yellow, which means the entire thing is getting redrawn. Feels like every 0.75s.

The textfield has a text selection. It appears that the insertion point rect may be getting redrawn, because I saw a few separate small yellow rects flash just at the start of the text. When I press tab to select the next control (and lose the selection) that redrawing stops. There are also full dialog repaints when there's an insertion point.

So it seems that insertion point flashing causes the entire bookmarks dialog to repaint, and the insertion point redraw is still active even when there's a selection.

Likely this affects Windows and Linux.

 
Status: Started (was: Assigned)
I have a terrible, terrible theory about this.

I think there are two things at play:

1) The cursor is "redrawn" even when not actually visible. This is not too hard to fix with a bit of a hack in Textfield::UpdateCursor().

2) The cursor blink invalidates the area under the cursor, which necessitates redrawing every view that intersects that area - ie, the BubbleFrameView for the bookmark bubble itself. There's no easy way around this, since Views has no way to know that the cursor blink won't draw half transparent or something and let the lower Views show through. Probably the easiest way to fix this is to move the cursor into its own Layer, which we position at the right spot when we need it, since that way the Layer for the rest of the dialog won't get touched as it blinks.
Re: 2), I noticed that when I mouse over some controls they redraw themselves many times, which I believe is an animation from one fill color to another. When this happens the entire dialog does not repaint. Seems like if your theory about 2) is true, the dialog would repaint on each control repaint?
Some controls have backing layers, which mean that layers underneath them don't have to be redrawn. Textfields don't have backing layers (they use their parent's layer), but some like combobox have their own.
Actually, ick: comboboxes *sometimes* have a backing layer.
What exactly is a "backing layer?" Backing layer means one thing on the Mac, but I'm guessing it's not what Views means.

I'm not totally familiar with the philosophy of Views's design, so if putting the insertion point in its own layer is the best solution, you should of course do that.
Project Member

Comment 6 by bugdroid1@chromium.org, Sep 23 2016

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

commit 1c77b2b6c04efe4e5d5d3ec5688616d65b8d0138
Author: ellyjones <ellyjones@chromium.org>
Date: Fri Sep 23 18:22:04 2016

Textfield: suppress cursor repaints when there's a selection

Without this, we do a considerable amount of repainting every timer tick.

BUG= 645262 

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

[modify] https://crrev.com/1c77b2b6c04efe4e5d5d3ec5688616d65b8d0138/ui/views/controls/textfield/textfield.cc
[modify] https://crrev.com/1c77b2b6c04efe4e5d5d3ec5688616d65b8d0138/ui/views/controls/textfield/textfield.h

Status: Fixed (was: Started)

Sign in to add a comment