Last Comment Bug 946987 - [Australis] curved tabs looks ugly when scaled up (hi-dpi)
: [Australis] curved tabs looks ugly when scaled up (hi-dpi)
Status: VERIFIED FIXED
[Australis:P3]
: regression
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: unspecified
: All Windows 8
-- normal (vote)
: Firefox 31
Assigned To: Matthew N. [:MattN] (PM if requests are blocking you)
:
: Dão Gottwald [:dao]
Mentors:
: 844795 879583 937850 996386 (view as bug list)
Depends on: 983761 990384
Blocks: win-hidpi australis-merge australis-tabs-v2 australis-tabs-win
  Show dependency treegraph
 
Reported: 2013-12-05 15:37 PST by Olli Pettay [:smaug] (pto-ish for couple of days)
Modified: 2015-05-11 15:54 PDT (History)
22 users (show)
anthony.s.hughes: in‑qa‑testsuite?
MattN+bmo: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
+
verified
verified


Attachments
ugly_tab.png (7.96 KB, image/png)
2013-12-05 15:37 PST, Olli Pettay [:smaug] (pto-ish for couple of days)
no flags Details
up-to-date ugly tab (4.43 KB, image/png)
2014-03-04 05:48 PST, Olli Pettay [:smaug] (pto-ish for couple of days)
no flags Details
check your dots per px (793 bytes, text/html)
2014-03-04 07:26 PST, Jim Mathies [:jimm]
no flags Details
windows-hidpi-tab-assets-01.zip (27.01 KB, application/zip)
2014-03-04 08:24 PST, Stephen Horlander [:shorlander]
no flags Details
patch (45.16 KB, patch)
2014-03-05 13:46 PST, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review
Make Start and End of Tab 32x32 (37.61 KB, patch)
2014-03-05 15:35 PST, Stephen Horlander [:shorlander]
MattN+bmo: feedback+
Details | Diff | Splinter Review
windows-hidpi-tab-assets-02.zip (22.41 KB, application/zip)
2014-03-05 15:38 PST, Stephen Horlander [:shorlander]
no flags Details
MattN WIP v.1 (44.11 KB, patch)
2014-03-15 15:28 PDT, Matthew N. [:MattN] (PM if requests are blocking you)
no flags Details | Diff | Splinter Review
Folded WIP with new path (92.35 KB, patch)
2014-03-26 19:21 PDT, Stephen Horlander [:shorlander]
no flags Details | Diff | Splinter Review
WIP 3 - Split some changes into bug 990384 and bug 990387 (83.26 KB, patch)
2014-03-31 22:54 PDT, Matthew N. [:MattN] (PM if requests are blocking you)
no flags Details | Diff | Splinter Review
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size (24.46 KB, patch)
2014-04-12 04:54 PDT, Matthew N. [:MattN] (PM if requests are blocking you)
mconley: review+
dolske: ui‑review+
sledru: approval‑mozilla‑aurora+
sledru: approval‑mozilla‑beta+
Details | Diff | Splinter Review
Ugly curved tabs (3.49 KB, image/png)
2014-04-14 06:22 PDT, Gary [:streetwolf]
no flags Details

Description User image Olli Pettay [:smaug] (pto-ish for couple of days) 2013-12-05 15:37:38 PST
Created attachment 8343383 [details]
ugly_tab.png

For some reason curved tabs look rather ugly on Win8. They look fine on Win7 (and on Linux)
Comment 1 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-01-22 05:47:40 PST
We're planning on working on HiDPI support for our UI on Windows after Australis.
Comment 2 User image :Gijs 2014-03-04 05:29:51 PST
(In reply to Matthew N. [:MattN] from comment #1)
> We're planning on working on HiDPI support for our UI on Windows after
> Australis.

Indeed, but I have to agree with Olli that this looks pretty terrible. Why does this look OK on OS X hidpi, and isn't there "just" some CSS we can port to make the tabs look less affrontingly awful? :-)
Comment 3 User image :Gijs 2014-03-04 05:30:13 PST
I'm upgrading this to P3- to at least get this on the radar for this week.
Comment 4 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2014-03-04 05:48:27 PST
Created attachment 8385295 [details]
up-to-date ugly tab
Comment 5 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2014-03-04 05:50:54 PST
I guess the tab a bit less ugly these days, now that we use right colors, but it still
looks very unfinished.
Comment 6 User image Jim Mathies [:jimm] 2014-03-04 06:47:28 PST
If someone can create some high-dpi version of these images, we can fix this. In metro we're doing 1.0x, 1.4x, and 1.8x.

chrome://browser/skin/tabbrowser/tab-background-start.png

Who is the ux lead for desktop currently?
Comment 7 User image Jim Mathies [:jimm] 2014-03-04 06:49:22 PST
(In reply to :Gijs Kruitbosch from comment #2)
> (In reply to Matthew N. [:MattN] from comment #1)
> > We're planning on working on HiDPI support for our UI on Windows after
> > Australis.
> 
> Indeed, but I have to agree with Olli that this looks pretty terrible. Why
> does this look OK on OS X hidpi, and isn't there "just" some CSS we can port
> to make the tabs look less affrontingly awful? :-)

Because someone took the time to generate 2.0x images for osx -  

http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/jar.mn#246
Comment 8 User image Mike Conley (:mconley) 2014-03-04 06:50:09 PST
(In reply to Jim Mathies [:jimm] from comment #6)
> If someone can create some high-dpi version of these images, we can fix
> this. In metro we're doing 1.0x, 1.4x, and 1.8x.
> 
> chrome://browser/skin/tabbrowser/tab-background-start.png
> 
> Who is the ux lead for desktop currently?

I think shorlander is the person to talk to here.
Comment 9 User image Jim Mathies [:jimm] 2014-03-04 07:26:01 PST
Created attachment 8385351 [details]
check your dots per px
Comment 10 User image Jim Mathies [:jimm] 2014-03-04 07:28:24 PST

We should probably morph this bug to a more general "update images resources for high-dpi on Windows" unless something like that already exists?

I can take the time to put together a patch now that metrofx is out the door.
Comment 11 User image :Gijs 2014-03-04 07:35:28 PST
(In reply to Jim Mathies [:jimm] from comment #10)
> 
> We should probably morph this bug to a more general "update images resources
> for high-dpi on Windows" unless something like that already exists?
> 
> I can take the time to put together a patch now that metrofx is out the door.

Updating all our images is significantly more work and isn't an Australis regression. There is a separate bug for it (bug 878288). I think we should focus this bug to be about the tabstrip. If we have time to fix other icons we can do that, but there are too many more pressing issues to fix for Australis right now.
Comment 12 User image Jim Mathies [:jimm] 2014-03-04 07:48:17 PST
wfm, if someone can post the images, I can put together a patch.
Comment 13 User image Stephen Horlander [:shorlander] 2014-03-04 08:24:44 PST
Created attachment 8385386 [details]
windows-hidpi-tab-assets-01.zip

Windows Tab Assets for 1.25x, 1.5x and 2x.

The 2x obviously scaled fine. For 1.25 and 1.5 I had to round up. Not sure what will happen at those stops; the CSS might need further tweaks.
Comment 14 User image Stephen Horlander [:shorlander] 2014-03-04 10:28:36 PST
Comment on attachment 8385386 [details]
windows-hidpi-tab-assets-01.zip

Tested these, don't think they will work as is. Going to need to tweak them first.
Comment 15 User image Dão Gottwald [:dao] 2014-03-04 11:02:26 PST
I don't think we want to end up with four versions of these images. Would scaling down the 2x images for 1.25x & Co. look better than scaling up the 1x images?
Comment 16 User image Stephen Horlander [:shorlander] 2014-03-04 11:11:00 PST
(In reply to Dão Gottwald [:dao] from comment #15)
> I don't think we want to end up with four versions of these images. Would
> scaling down the 2x images for 1.25x & Co. look better than scaling up the
> 1x images?

I tried that. It didn't look great.
Comment 17 User image Mike Conley (:mconley) 2014-03-04 11:14:41 PST
I also wonder how scaling down would affect our TART numbers...
Comment 18 User image Dão Gottwald [:dao] 2014-03-04 11:17:02 PST
(In reply to Stephen Horlander [:shorlander] from comment #16)
> (In reply to Dão Gottwald [:dao] from comment #15)
> > I don't think we want to end up with four versions of these images. Would
> > scaling down the 2x images for 1.25x & Co. look better than scaling up the
> > 1x images?
> 
> I tried that. It didn't look great.

Does it look better than upscaling? :)

(In reply to Mike Conley (:mconley) from comment #17)
> I also wonder how scaling down would affect our TART numbers...

Probably not worse than the upscaling we're doing today.

Also, do we have any idea whether some scaling factors might be more common than others?
Comment 19 User image Stephen Horlander [:shorlander] 2014-03-04 12:38:00 PST
(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to Stephen Horlander [:shorlander] from comment #16)
> > (In reply to Dão Gottwald [:dao] from comment #15)
> > > I don't think we want to end up with four versions of these images. Would
> > > scaling down the 2x images for 1.25x & Co. look better than scaling up the
> > > 1x images?
> > 
> > I tried that. It didn't look great.
> 
> Does it look better than upscaling? :)

Well, yes ;)

Here is what it looks like scaled to 150%. Top is upscaled with the current 1x image, second is downscaled with the 2x image and the bottom is a properly sized 1.5x image.

http://cl.ly/image/440T2g1d2M2V

Downscaling does look nicer than upscaling but still fuzzy. The specifically sized image looks a lot better.
Comment 20 User image Justin Dolske [:Dolske] 2014-03-04 14:06:09 PST
*** Bug 879583 has been marked as a duplicate of this bug. ***
Comment 21 User image Jim Mathies [:jimm] 2014-03-05 13:46:41 PST
Created attachment 8386364 [details] [diff] [review]
patch
Comment 22 User image Stephen Horlander [:shorlander] 2014-03-05 15:35:01 PST
Created attachment 8386436 [details] [diff] [review]
Make Start and End of Tab 32x32

(In reply to Jim Mathies [:jimm] from comment #21)
> Created attachment 8386364 [details] [diff] [review]
> patch

I checked your patch and it has the same problems I was running into. Namely rounding errors causing gaps and overlap between the start, middle and end of the tab.

I think before we can cleanly support 100%, 125%, 150% and 200% stops the base image will have to evenly multiply by those stops.

Currently the start and end elements are 31 x 30. This patch changes tab start and end to 32 x 32. This also even scaling. On OS X it does have a bug that I can't figure out. Increasing the tab height and the negative margin on the nav-bar breaks in Customize Mode, with lightweight themes and in fullscreen. Not sure where we are doing those calculations though.
Comment 23 User image Stephen Horlander [:shorlander] 2014-03-05 15:38:16 PST
Created attachment 8386437 [details]
windows-hidpi-tab-assets-02.zip

New 32x32 base images.
Comment 24 User image Szmozsánszky István [:flaki] 2014-03-08 00:00:25 PST
Wouldn't using an SVG as the primary asset ease the adoption of different pixel densities here? I'm well aware of SVG not being "the magic bullet" (as in "one size fits all"), but should be easier to customize (or is it?) to acting pixel density on launch/runtime.

As it was mentioned in the sister bug 878288, comment 7 even performance shouldn't degrade too much, due to improved runtime caching of SVG assets (bug 764299), but we could always generate and cache these images on (first) launch, if runtime caching turns out to be less performant than ideal.

The gains would, then be obvious, not having to re-generate (and store) all the assets for the myriad of different densities. Might this work? I'm not sure what are the exact tweaks needed for specific densities, is it possible that these could be automated/algorithmized?
Comment 25 User image Stephen Horlander [:shorlander] 2014-03-08 07:49:56 PST
(In reply to Szmozsánszky István [:flaki] from comment #24)
> Wouldn't using an SVG as the primary asset ease the adoption of different
> pixel densities here? I'm well aware of SVG not being "the magic bullet" (as
> in "one size fits all"), but should be easier to customize (or is it?) to
> acting pixel density on launch/runtime.
>
> As it was mentioned in the sister bug 878288, comment 7 even performance
> shouldn't degrade too much, due to improved runtime caching of SVG assets
> (bug 764299), but we could always generate and cache these images on (first)
> launch, if runtime caching turns out to be less performant than ideal.

If I recall correctly we were using SVG for the image and not just the clip-path during on of the iterations. I think it caused a performance hit though. Maybe something to try again with the improvements to SVG, but not at this stage.

> The gains would, then be obvious, not having to re-generate (and store) all
> the assets for the myriad of different densities. Might this work? I'm not
> sure what are the exact tweaks needed for specific densities, is it possible
> that these could be automated/algorithmized?

If the base SVG image is designed correctly it should just scale correctly. Would have to try it though to be sure because rounding issues and pixel snapping are often issues when trying to scale SVG.
Comment 26 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-03-13 18:24:05 PDT
(In reply to Stephen Horlander [:shorlander] from comment #22)
> Currently the start and end elements are 31 x 30. This patch changes tab
> start and end to 32 x 32. This also even scaling. On OS X it does have a bug
> that I can't figure out. Increasing the tab height and the negative margin
> on the nav-bar breaks in Customize Mode, with lightweight themes and in
> fullscreen. Not sure where we are doing those calculations though.

Change 1px to 2px at https://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/browser.css?rev=cc1fdefca201&mark=2773#2759

There will be a new problem with the new customize mode outlines though.

I'll run my screenshot tool to try find problems and look at the patch some more.
Comment 27 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-03-15 15:28:16 PDT
Created attachment 8391774 [details] [diff] [review]
MattN WIP v.1

shorlander: the new Windows curves don't connect as nicely to the nav-bar border (at the bottom of the curve). 
* Current 1.0x: http://grab.by/vaEA 
* 32x32  1.25x: http://grab.by/vaEG
* 32x32   2.0x: http://grab.by/vaEy

On 1.25x it's very noticeable that the highlight on the nav-bar is twice the thickness as the highlight at the bottom of the tab curve. You can see the difference in the images alone. The 1.25x curve goes to the edge of the image whereas it doesn't with @1x and @2x.

Stephen, can you fix the new images so that the highlight lines up better on the bottom? It's easiest to see on black themes.
Comment 28 User image Dão Gottwald [:dao] 2014-03-17 06:19:02 PDT
*** Bug 937850 has been marked as a duplicate of this bug. ***
Comment 29 User image Jim Mathies [:jimm] 2014-03-20 09:01:23 PDT
*** Bug 844795 has been marked as a duplicate of this bug. ***
Comment 30 User image Stephen Horlander [:shorlander] 2014-03-26 19:21:46 PDT
Created attachment 8397531 [details] [diff] [review]
Folded WIP with new path

Updated images. Just folded all the various WIP patches into one.
Comment 31 User image Lawrence Mandel [:lmandel] (use needinfo) 2014-03-27 13:14:27 PDT
This will be prioritized by the desktop team along with the rest of the Australis follow-up work. The desktop team will not fix this in 29 or 30. As such, dropping the tracking flags.
Comment 32 User image Lawrence Mandel [:lmandel] (use needinfo) 2014-03-27 15:23:15 PDT
There was some confusion by a few of us in our earlier conversation about this bug. MattN is on this and it is targeted at 29. Restoring the tracking flags that I removed.
Comment 33 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-03-31 22:54:34 PDT
Created attachment 8399818 [details] [diff] [review]
WIP 3 - Split some changes into bug 990384 and bug 990387
Comment 34 User image Sylvestre Ledru [:sylvestre] 2014-04-07 04:33:19 PDT
Matthew, are you still targeting 29 for this bug? Thanks
Comment 35 User image Dão Gottwald [:dao] 2014-04-09 04:54:40 PDT
*** Bug 988868 has been marked as a duplicate of this bug. ***
Comment 36 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-12 04:54:31 PDT
Created attachment 8405754 [details] [diff] [review]
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size

(In reply to Sylvestre Ledru [:sylvestre] from comment #34)
> Matthew, are you still targeting 29 for this bug? Thanks

We're going to make a decision by Monday as to whether we'll do anything for 29.
--
This patch definitely makes the stroke crisper although it still makes the connection problem on the bottom of the curve look somewhat worse than the blurry connection IMO. This patch is much lower risk though so if people think this is better than m-c then I'm fine with taking the patch.

Screenshots of stock m-c and with this patch applied are here (207 MB zip file): https://drive.google.com/file/d/0B8j8iLTl0K0UOUhwQXU3ekVzenc/edit?usp=sharing
Comment 37 User image Sylvestre Ledru [:sylvestre] 2014-04-12 05:09:49 PDT
OK. Do you know at what time? I am going to launch the go to build for beta 8 Monday. If it does not make it for beta 8, it is going to be too late for 29.
Comment 38 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2014-04-12 05:31:08 PDT
MattN, by any chance are there tryserver builds for the approach 2?
Comment 39 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-12 05:38:08 PDT
(In reply to Olli Pettay [:smaug] from comment #38)
> MattN, by any chance are there tryserver builds for the approach 2?

I just happened to push them: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mozilla@noorenberghe.ca-d5ca06b23110/
Comment 40 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-12 05:39:25 PDT
(In reply to Sylvestre Ledru [:sylvestre] from comment #37)
> OK. Do you know at what time? I am going to launch the go to build for beta
> 8 Monday. If it does not make it for beta 8, it is going to be too late for
> 29.

What time would you like it landed by? Decision makers are in Eastern and Pacific timezones.
Comment 41 User image Sylvestre Ledru [:sylvestre] 2014-04-12 05:46:00 PDT
Before 11PM PDT would be great!
Comment 42 User image Justin Dolske [:Dolske] 2014-04-12 13:13:13 PDT
Comment on attachment 8405754 [details] [diff] [review]
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size

I went thought the pile of screenshots Matt generated for this patch. I found of number of small glitches, but they're all present in the screenshots of m-c today. So this patch is improving the tabs, but I don't see any significant visual regressions. We'll come back post-29 to improve Windows hidpi further.
Comment 43 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-12 15:35:21 PDT
Comment on attachment 8405754 [details] [diff] [review]
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Initial implementation of Australis tabs (bug 738491)
User impact if declined: Users with >1dppx 
Testing completed (on m-c, etc.): Automated screenshot collection reviewed by dolske, myself, and others.
Risk to taking this patch (and alternatives if risky): Low risk image addition and copying some CSS from OS X to use the images with 1.25 dppx and higher.
String or IDL/UUID changes made by this patch: None
Comment 44 User image Mike Conley (:mconley) 2014-04-12 19:45:21 PDT
Comment on attachment 8405754 [details] [diff] [review]
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size

Review of attachment 8405754 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me. The placement of the block is a little odd - if you wanted to move it closer to the tabs.inc.css include, that might make more sense.

Thanks Matt!

::: browser/themes/windows/browser.css
@@ +2887,5 @@
>  }
>  
>  /* End private browsing indicators */
>  
> +@media (min-resolution: 1.25dppx) {

Is there a particular reason why this block is here? If not, it might make more sense to put this nearer to where tabs.inc.css is included.
Comment 45 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-13 01:16:07 PDT
(In reply to Mike Conley (:mconley) from comment #44)
> Comment on attachment 8405754 [details] [diff] [review]
>
> Is there a particular reason why this block is here? If not, it might make
> more sense to put this nearer to where tabs.inc.css is included.

Nope, I think that was just like that from another patch and I didn't notice. Fixed.

https://hg.mozilla.org/integration/fx-team/rev/5c1bbf1f4820
Comment 46 User image Ryan VanderMeulen [:RyanVM] 2014-04-13 16:32:52 PDT
https://hg.mozilla.org/mozilla-central/rev/5c1bbf1f4820
Comment 47 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-13 17:18:04 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/965a0df971b9
Comment 48 User image Matthew N. [:MattN] (PM if requests are blocking you) 2014-04-13 17:30:30 PDT
https://hg.mozilla.org/releases/mozilla-beta/rev/975b76d0b1c0
Comment 49 User image Gary [:streetwolf] 2014-04-14 06:22:02 PDT
Created attachment 8406126 [details]
Ugly curved tabs

Running from inbound which includes this patch and I still see ugly curved tabs.  My dpi is 120 (125%) on Windows 8.1.1.

Built from https://hg.mozilla.org/integration/mozilla-inbound/rev/2e83d29d7f6b

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Comment 50 User image Gary [:streetwolf] 2014-04-14 06:23:26 PDT
btw... I've been using this snippet of css code to make the tabs flow nicely into the border:

#nav-bar {
    border-top: 2px solid  hsl(210, 6.1%, 71.1%) !important;
    background-clip: padding-box;}
Comment 51 User image Dão Gottwald [:dao] 2014-04-14 23:49:05 PDT
*** Bug 996386 has been marked as a duplicate of this bug. ***
Comment 52 User image Matthew Bonner 2014-04-15 04:37:31 PDT
The problem I think is the use of images, and this makes the tabs not scale well, can we not achieve the same results by replacing the images with something that will work better, such as a mix of CSS gradients, and a border radius?
Comment 53 User image :Gijs 2014-04-15 04:40:06 PDT
(In reply to Matthew Bonner from comment #52)
> The problem I think is the use of images, and this makes the tabs not scale
> well, can we not achieve the same results by replacing the images with
> something that will work better, such as a mix of CSS gradients, and a
> border radius?

I would be surprised if this kind of curve were doable in pure CSS gradients + border radius without having to have many boxes. Even if it were, we did extensive performance testing on these (and still do automated performance testing on them) and how they affect the animation. I would be (pleasantly) surprised if there were a way we could avoid images and maintain performance.
Comment 54 User image Justin Dolske [:Dolske] 2014-04-15 15:47:12 PDT
(In reply to Gary [:streetwolf] from comment #49)
> Created attachment 8406126 [details]
> Ugly curved tabs

That's expected with this patch. Due to time constraints for shipping Firefox 29, we can't make it perfect for all situations. Bug 995733 tracks followup work.
Comment 55 User image Sylvestre Ledru [:sylvestre] 2014-06-04 06:16:46 PDT
Comment on attachment 8405754 [details] [diff] [review]
Approach 2 - v.1 Downscale @2x images for 1.25dppx and higher with the existing tab size

Big fingers. Removing the unwanted feedback flag.
Comment 56 User image Cornel Ionce [QA] (:cornel_ionce) 2014-06-30 02:26:44 PDT
Tested on a Microsoft Surface Pro 2 device running Windows 8.1 64bit using Firefox 30, build ID: 20140605174243 and Firefox 31 beta 5, build ID: 20140626181429.

Marking this issue verified as further work is tracked in bug 995733.

Note You need to log in before you can comment on or make changes to this bug.