Re-enable subpixel rendering for Ash system menu labels |
||||||
Issue descriptionSubpixel rendering for labels within the system menu was disabled because they were getting painted on non-opaque backgrounds and this is not supported. See: * SetupLabelForTray() in tray_utils.cc * ImeListItemView constructor (and possibly other places)
,
Jan 28 2017
I need the configuración for my Moto G3
,
Jan 31 2017
I can own this but why target m57? It's pretty subtle.
,
Jan 31 2017
If you think it looks OK on low-dpi devices then it doesn't seem super high priority to me. I haven't seen it -- I don't have a low-dpi device on my desk.
,
Feb 1 2017
Sounds low-priority to me too. We constantly break subpixel rendering in the omnibox, which is much more noticeable, and nobody except me cares. :-/ I'm attaching a screenshot showing how things look on a ToT lumpy build. I have to look really, really closely to tell which text is missing subpixel rendering. (Spoiler: just "US Dvorak keyboard", "Connected to Ethernet", and the date, I think)
,
Feb 1 2017
SetupLabelForTray() in tray_utils.cc is applied to labels that are in the tray, not the system menu, i.e. white text. I don't think subpixel rendering does anything to white text.
,
Feb 1 2017
For System menu labels check out TrayPopupUtils::CreateDefaultLabel().
,
Feb 1 2017
I don't think there's any inherent reason we can't use subpixel rendering for white text (and I believe that we already do by default), although it may look worse than dark-colored text on a light background (for complicated reasons involving gamma that I don't understand). The tray has a transparent background, though, so we can't use it there.
,
Feb 1 2017
I think I was confused by the fact that my system wasn't properly doing subpixel at all anywhere. But wrt the tray labels, I did find that function and it seems like the best fix is also the simplest one, which is to just add backgrounds to the labels. We could add backgrounds instead to anything that holds a label, but I'm not sure what win that would provide --- it's just one more step you have to remember to do (even if we make a utility function called TrayPopupUtils::ConfigureRow or whatever). This doesn't break ripples or anything else I can find.
,
Feb 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47a9403d16ca37b99175b07cea5ee41c574d36c5 commit 47a9403d16ca37b99175b07cea5ee41c574d36c5 Author: estade <estade@chromium.org> Date: Wed Feb 01 18:57:56 2017 Apply subpixel rendering to labels in cros system menu. BUG= 686363 Review-Url: https://codereview.chromium.org/2667963006 Cr-Commit-Position: refs/heads/master@{#447565} [modify] https://crrev.com/47a9403d16ca37b99175b07cea5ee41c574d36c5/ash/common/system/chromeos/ime_menu/ime_list_view.cc [modify] https://crrev.com/47a9403d16ca37b99175b07cea5ee41c574d36c5/ash/common/system/tray/tray_popup_utils.cc
,
Feb 1 2017
,
Feb 1 2017
Based on the discussion it seems ok to just leave this in m-58 and not merge back to 57.
,
Feb 21 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tdander...@chromium.org
, Jan 28 2017Owner: est...@chromium.org