Quasi-meta bug to cover the work needed to: - Eliminate the fixed height images (bug 350194) - Draw borders with border-radius where appropriate - Reduce the number of separate images needed - Reduce Ts/Txul impact

Border-radius isn't anti-aliased on Linux, is it?

(In reply to comment #1) > Border-radius isn't anti-aliased on Linux, is it? > I don't believe so and mconnor asked me to check that out just yesterday ;) Background layering would be nice, but that's not likely to happen for 1.9. I was hoping to just get away with using border-image.

I was testing with padding-left / padding-right (i.e. no extra xul boxes), one background image and border-radius on Windows, and compared to the current appearance I couldn't really tell a difference. If border-radius could be fixed on Linux, I think that would be the ideal solution.

(In reply to comment #3) True, it's barely noticeable: http://screwedbydesign.com/images/csstabs.png (note: really old image) and something we might be willing to do without if it comes down to it.

I'd rather use native tabs on Linux if we can't get the current tabs done, because this is a real perf win...

This takes care of winstripe and gnomestripe (already landed) - I'll file a followup for sticking a band-aid on pinstripe until the new theme's in.

I think you should use rgba() or native ThreeD* colors; either way would be better than static opaque colors.

(In reply to comment #7) > I think you should use rgba() or native ThreeD* colors; either way would be > better than static opaque colors. for the tab borders

Yes, that's my plan - but since rgba() hasn't really been used at all in the UI, I want an established perf baseline with the other bits from this patch before mucking with it.

OK, but for the selected tab we should probably use ThreeDShadow anyway.

(In reply to comment #10) > OK, but for the selected tab we should probably use ThreeDShadow anyway. or ThreeDDarkShadow actually

Comment on attachment 288618 [details] [diff] [review] Patch I'm a tad nervous about the colors for the borders, but I'm otherwise ok with this. I assume this doesn't break Mac, correct?

mozilla/browser/base/content/browser.css 1.40 mozilla/browser/base/content/tabbrowser.xml 1.251 mozilla/browser/themes/winstripe/browser/browser.css 1.135 mozilla/browser/themes/winstripe/browser/jar.mn 1.61 mozilla/browser/themes/winstripe/browser/tabbrowser/tab-active-bkgnd.png 1.1 mozilla/browser/themes/winstripe/browser/tabbrowser/tab-bkgnd.png 1.1

The windows box is still a bit jumpy (though talos seems to confirm similar drops), but so far it looks like the results are as follows: Ts before: ~1870ms Ts after: ~1830ms Txul before: ~469ms Txul after: ~450ms

This was a 2% Ts win and 4% Txul improvement even though the tab bar isn't shown by default? Wow.

Hi ryan, do you have a testcase for this bug so QA can verify this fix?

this is mostly code cleanup.

Dao, since this is code cleanup, can you confirm this is fixed in latest builds? Thanks.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121405 Minefield/3.0b3pre