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

Issue 628337 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Create 1.5X icons for CoreUI and omnibox

Project Member Reported by rpop@chromium.org, Jul 14 2016

Issue description

Comment 1 by est...@chromium.org, Jul 14 2016

I still want to just change the existing icons to work better at 1.5x. I'm going to continue repeating myself until I hear an explanation as to why this won't work (design wise). This seems more graceful than adding yet another nearly identical icon definition.
Depends what icons you are talking about Evan.
Most of the icons were deliver in 1x and 2x because we wanted them to be different from 1x an 2x.
Cc: bettes@chromium.org
+bettes@
I agree with Evan.  The specific example of needing a 1.5x version given so far was the omnibox lock, but that turns out to be because it was designed assuming a particular font baseline, which the icon designer can't assume.  Such an icon should be redesigned to simply scale correctly and then we should be asked to position it appropriately programmatically.

I'm already unhappy with how many icons are different between 1x and 2x, and the idea of adding yet more for 1.5x is distasteful.  Note that 1.5x is far from the only non-integral scale factor used.  1.25x, 1.4x, 1.75x, and 1.8x are also possible.  Probably in the future yet more will be possible, especially higher values like 3x and 4x.  It's simply not scalable to try and have different icons for every different factor, and icons optimized specifically for 1x or 2x aren't necessarily going to look good scaled.  We need to be designing icons that either work at all scale factors, or at least can cover whole ranges of scales with one icon.
It's not possible to design an icon that scales well at 1.25, 1.5, 1.75, 1.8, 2 and 3. We will get blurriness and we need to be ok with that. If not, we need to be ok with getting icons per multiplier. 

Beyond this, the reason why we have different 1x and 2x is because we want different rendering per multiplier. If we used a scalable version from 1x to 2x, the icons wouldn't be looking as elegant as we want them to get. 

For the omnibox, my assumption is that a scaled icon wouldn't look as nice as what max did and that programmatic alignment  to baseline might not work with another icon because it might look misaligned depending on the size of the icon.

I'm happy with the current state personally. We have great rendering at 1x and 2x we have blurriness on icons in 1.5 but for me the ommibox and tab rendering issues are more prominent on this multiplier. 

 

Comment 6 by est...@chromium.org, Jul 18 2016

I don't think anyone's asking for perfection at 1.25, 1.75 or 1.8, at least not until a lot of users are on those scale factors. I agree that designing an icon to look good at arbitrary scale factors is very hard. But I wouldn't think it's impossible to design a single icon to cover 2x and 1.5x (depending on the icon). And if you just design for 2x and 1.5x then you get 3x for "free" (in the sense that you're guaranteed there won't be blurriness).
It is not. if you have a 2pt line weight on 1x, which is what we use, you get 3px on 1.5x. Problem is measurement of the chrome UI are aligned on even number, therefore, if you have a central line, like on the back button, it will be aligned halfway. 

Plus 2pt line weight look chubby on 2x so what I did is creating 2x specific icons that have a 3px line weight. 

Same principle for the overall UI. See the image attached for context.
if we were lazy, we absolutely could have 1 scalable resource for everything but it would:
- Still be blurry on non-integral scale factors
- Would look worse on 2x scale factor. unless you thing "2x - scaled - 2pt line weight" is looking better than " 2x - custom icons (today)"



comparison.png
194 KB View Download
Components: UI>Browser>Omnibox UI

Comment 9 by est...@chromium.org, Jul 21 2016

So it seems like pkasting, sgabriel and myself are all against creating additional assets (for various reasons). Depending on the priority of this issue, maybe we should have a meeting to discuss options?
This bug appeared in my "random available omnibox bugs" list today.  Is there something we should do with it?  Close?
Cc: -maxwalker@chromium.org
Owner: maxwalker@chromium.org
Status: Untriaged (was: Available)
I'm assigning to Max to evaluate the state of the world today w.r.t. 1.5x and decide if we're happy with what we have or need to take action here.
if we decide we need this we probably should address  bug 647286 
Components: -UI
Labels: Needs-Feedback Hotlist-Polish
Status: Assigned (was: Untriaged)
Actually assigning to Max per comment #11 ("to evaluate the state of the world today w.r.t. 1.5x and decide if we're happy with what we have or need to take action here.")


maxwalker: can you respond to the question in #11?
Cc: jdonnelly@chromium.org
Scaling the 1x toolbar icons (back, forward, reload) to 1.5x results in icons with 3px line weight which is generally what we want. However, these 1.5x icons look blurry since they aren't aligned with the pixel grid anymore. Would it be possible to programmatically shift the icons by 0.5px? That would give us sharp toolbar icons at 1.5x without creating additional icons assets.
1.5x.png
357 KB View Download
Would that give us correct results though? Wouldn't the padding be uneven? (e.g. 2px on the left and 1px on the right)
Yes, however this is what we already do for 2x icons (since it's impossible to center a 3px line in a 48px square) and seems acceptable to me.
Alignment (with hover states).png
200 KB View Download
In that case yes, it's possible to do this on our end, but someone will need to do the work to make it happen.
Labels: -Needs-Feedback
Owner: ----
Status: Available (was: Assigned)
maxwalker@ provided the needed feedback.  Marking as available.

Sign in to add a comment