New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 601135 link

Starred by 2 users
Status: WontFix
Owner:
█ bruthig@chromium.org
Last visit > 30 days ago
Closed: May 2016
Cc:
danakj@chromium.org
weiliangc@chromium.org
vmp...@chromium.org
ajuma@chromium.org
█ bruthig@chromium.org
enne@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Menu items have a 1 pixel wide line on bottom and right side at display resolution 683x384

Project Member Reported by bruthig@chromium.org, Apr 6 2016 
Version: ToT
OS: ChromeOS

When trying to fix  issue 596073  as per (https://codereview.chromium.org/1812303002/) I encountered a weird visual artifact on MenuScrollViewContainer::MenuScrollViews.  It was a 1 pixel wide 'black' line along the bottom and right side of the View.  This was found when working on a Glimmer device and would only appear when the display resolution was set to the minimum 683x384 and the MenuScrollViewContainer::MenuScrollView's Layer was set to fill the bounds opaquely.

Steps to reproduce: (Assuming https://codereview.chromium.org/1812303002/ has landed...)

1. Update the MenuScrollViewContainer::MenuScrollView's Layer so that it fills bounds opaquely.
2. Build, (deploy) run
3. Set display resolution to 683x384
4. Open a menu (e.g. Bookmark folder menu, or AppMenu)

Expected:
(See attached 'menu item black pixel line - expected.png') 

Actual:
(See attached 'menu item black pixel line - actual.png') 

The suspicion is that contents size and the buffer used during rastering do not properly scale together and the bottom and right rows are filled in with some unwanted color.

Other info:
- Glimmer's have a native display resolution of 1366x768.
menu item black pixel line - expected.png
489 KB View Download
menu item black pixel line - actual.png
487 KB View Download

Comment 1 by enne@chromium.org, Apr 6 2016 

When you set something to fill the contents opaquely, you also need to set the safe opaque background color of the layer to something non-transparent.  This is the color that eventually gets used in RasterSource::PrepareForPlaybackToCanvas to draw underneath the stretched opaque contents that don't completely fill their bottom/right rows.  My guess is that you need to set this color.

Other things to do are to run in a debug build where RasterSource uses a bunch of DebugColors to fill in missing contents so you can see if it's something like MissingResizeInvalidations or NonPaintedFillColor.  That might indicate something else is going on.

Comment 2 by bruthig@chromium.org, Apr 12 2016

Owner: bruthig@chromium.org
Status: Started (was: Untriaged)

Comment 3 by bruthig@chromium.org, May 3 2016 

Marking as WontFix since the fix for  issue 604415  precludes this from happening.

Comment 4 by bruthig@chromium.org, May 3 2016

Status: WontFix (was: Started)
Marking as WontFix since the fix for  issue 604415  precludes this from happening.
►

Sign in to add a comment