578620 - [Meta] Enabling DW/D2D causes changes of Firefox Button

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Peter Henkel [:Terepin]]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; sk; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre

When you enable DirectWrite, the vertical size of Firefox Button will increase.

Reproducible: Always

Comment 1

[Peter Henkel [:Terepin]]

Attachment: Normal Firefox Button

Comment 2

[Peter Henkel [:Terepin]]

Attachment: Bigger Firefox Button

Comment 3

[Joe Drew (not getting mail)]

This looks like a font rendering change. UX team, should the size of the button change in response?

Comment 4

[Stephen Horlander [:shorlander]]

(In reply to comment #3)
> UX team, should the size of the button change in response?

No, the button should match the default size of the other window buttons(min/max/close). Right now the CSS is setting the size of the button with padding using em. Which might be why the button size would change if the font rendering changes.

Comment 5

[Joe Drew (not getting mail)]

Can someone confirm this?

Comment 6

[Peter Henkel [:Terepin]]

Just a note: The bold font occurs only in my current profile, but not in clean profile. Not sure why, but the size of the button itself is changing regardless which profile I'm using.

Comment 7

[Joe Drew (not getting mail)]

I can't block on this until it's confirmed. Please renom once this bug is confirmed.

Comment 8

[[not reading bugmail]]

I've seen this too.  Seems font related.

Comment 9

[Oskar Ivanić (:icecold)]

Happens to me also.

Comment 10

[Joe Drew (not getting mail)]

We will get different font metrics with DirectWrite. The Firefox button should be sized such that they don't negatively affect it!

Comment 11

[Dão Gottwald [:dao]]

We deal with the height, but what about the overly bold font? Looks pretty bad if you compare the two screenshots.

Comment 12

[Joe Drew (not getting mail)]

Peter suggested it doesn't always happen; have you seen it too, Dão?

Comment 13

[Dão Gottwald [:dao]]

Looks slightly bolder with DirectWrite over here, but not like in the attached screenshot.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #12)
> Peter suggested it doesn't always happen; have you seen it too, Dão?

Apparently Gavin sees it: https://bug555845.bugzilla.mozilla.org/attachment.cgi?id=468744

Comment 15

[:Gavin Sharp [email: [e-mail]]]

That screenshot is from johnath's new machine, in case you want to see it in person, Joe!

Comment 16

[Joe Drew (not getting mail)]

I only want to block on the investigation of what's making this font apparently render bolder.

Comment 17

[Oskar Ivanić (:icecold)]

Attachment: Enabling DirectWrite causes increase of vertical size of Firefox Button

Here is picture of the bug on my PC.
From user view it seems like easy fix, can someone work a little bit on this?

OS: Windows 7
GPU: Nvidia 8400GS
Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre

Comment 18

[TimoT]

This bug will cause problems with https://bugzilla.mozilla.org/show_bug.cgi?id=593950

Basically, if the gap between min/max/close buttons and tabs is reduced to the designed 3px (?), there will be no room between tabs and the Firefox button when D2D is on (without D2D we get the correct gap, since the Firefox button is the same size with the window controls).

Comment 19

[Stanimir Stamenkov]

I've found similar entry: Bug 601152

Comment 20

[Bas Schouten (:bas.schouten)]

John, could you have a quick look? This sounds like WONTFIX to me but I'm not 100% sure.

Comment 21

[Leman Bennett [Omega]]

Attachment: Mirroring/Artifacts issue

This is a quirk with DirectWrite in general. 

Text of websites shift whenever its enabled. It even causes a slight artifacting or mirroring issue in Google Reader when in list view.

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #20)
> John, could you have a quick look? This sounds like WONTFIX to me but I'm not
> 100% sure.

ping?

Comment 23

[John Daggett (:jtd)]

The font metrics for the two cases is different:

GDI metrics:

0[2ab098]: (FindFontForStyle) name: Segoe UI, sty: 00, wt: 700, sz: 12.0 -> Segoe UI Bold
Font: 04F9D748 (Segoe UI Bold) size: 12.000000
    emHeight: 12.000000 emAscent: 9.000000 emDescent: 3.000000
    maxAscent: 12.000000 maxDescent: 3.000000 maxAdvance: 27.000000
    internalLeading: 3.000000 externalLeading: 0.000000
    spaceWidth: 3.000000 aveCharWidth: 7.000000 xHeight: 6.000000
    uOff: -1.000000 uSize: 1.000000 stOff: 3.000000 stSize: 1.000000 supOff: 6.000000 subOff: 2.000000
0[2ab098]: InitTextRun 4e61508 fontgroup 34347a8 (Segoe UI) lang: en-us len 10 TEXTRUN " Minefield" ENDTEXTRUN

DirectWrite metrics:

0[52b098]: (FindFontForStyle) name: Segoe UI, sty: 00, wt: 700, sz: 12.0 -> Segoe UIBold
Font: 03DBF920 (Segoe UIBold) size: 12.000000
    emHeight: 12.000000 emAscent: 9.176471 emDescent: 2.823529
    maxAscent: 13.000000 maxDescent: 4.000000 maxAdvance: 21.855469
    internalLeading: 4.000000 externalLeading: 0.000000
    spaceWidth: 3.310547 aveCharWidth: 7.078125 zeroOrAve: 6.902344 xHeight: 6.000000
    uOff: -1.042969 uSize: 1.000000 stOff: 3.105469 stSize: 1.000000 supOff: 6.000000 subOff: 6.000000
0[52b098]: InitTextRun 551a728 fontgroup 54d8ca0 (Segoe UI) lang: en-us len 10 TEXTRUN " Minefield" ENDTEXTRUN

I need to dig into the layout code a bit more to figure out the exact calculation used but I would bet the height is set to (maxAscent + maxDescent + internalLeading).  That would explain the slightly different heights, 18px vs. 20px.


GDI code:

if (0 < GetOutlineTextMetrics(dc.GetDC(), sizeof(oMetrics), &oMetrics)) {
    mMetrics->emHeight = metrics.tmHeight - metrics.tmInternalLeading;
    gfxFloat typEmHeight = (double)oMetrics.otmAscent - (double)oMetrics.otmDescent;
    mMetrics->emAscent = ROUND(mMetrics->emHeight * (double)oMetrics.otmAscent / typEmHeight);
    mMetrics->emDescent = mMetrics->emHeight - mMetrics->emAscent;
mMetrics->maxAscent = metrics.tmAscent;
mMetrics->maxDescent = metrics.tmDescent;


DirectWrite code:

mFontFace->GetMetrics(&fontMetrics);
mMetrics.xHeight =
    ((gfxFloat)fontMetrics.xHeight /
               fontMetrics.designUnitsPerEm) * mAdjustedSize;

mMetrics.maxAscent = 
    ceil(((gfxFloat)fontMetrics.ascent /
               fontMetrics.designUnitsPerEm) * mAdjustedSize);
mMetrics.maxDescent = 
    ceil(((gfxFloat)fontMetrics.descent /
               fontMetrics.designUnitsPerEm) * mAdjustedSize);

mMetrics.internalLeading = 
    ceil(((gfxFloat)(fontMetrics.ascent + 
                fontMetrics.descent - 
                fontMetrics.designUnitsPerEm) / 
                fontMetrics.designUnitsPerEm) * mAdjustedSize);

The inclusion of ceil() was done for bug 549190.

Comment 24

[Dão Gottwald [:dao]]

In case the font metrics are correct, bug 610071 will take care of not screwing up the button size.

The bold rendering is still an issue (see the screenshots on <http://blog.mozilla.com/rstrong/2010/11/06/what-to-do/>).

Comment 25

[Dão Gottwald [:dao]]

The excessively bold rendering seems to happen only with D2D enabled.

Comment 26

[Peter Henkel [:Terepin]]

Changed name of bug. Dao, fill bug for bold font.

Thanks for fixing them!

Comment 27

[Peter Henkel [:Terepin]]

Attachment: Hardware acceleration off

Comment 28

[Peter Henkel [:Terepin]]

Attachment: Hardware acceleration on

Enabling HW acceleration causes increase of size:
1. On FXB's bottom by 1px,
2. On top of tabs by 1px.

Comment 29

[Peter Henkel [:Terepin]]

Forgot to ask: Should I fill another bug for it? Or it is something else?

Comment 30

[Peter Henkel [:Terepin]]

Not happening anymore.