Closed Bug 578620 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: Graphics, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Terepin, Assigned: jtd)

References

(Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(4 files, 2 obsolete files)

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
Attached image Normal Firefox Button (obsolete) (deleted) —
Attached image Bigger Firefox Button (obsolete) (deleted) —
blocking2.0: --- → ?
Keywords: regression
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
Blocks: dwrite
This looks like a font rendering change. UX team, should the size of the button change in response?
(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.
Can someone confirm this?
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.
I can't block on this until it's confirmed. Please renom once this bug is confirmed.
blocking2.0: ? → -
I've seen this too. Seems font related.
Happens to me also.
Status: UNCONFIRMED → NEW
blocking2.0: - → ?
Ever confirmed: true
We will get different font metrics with DirectWrite. The Firefox button should be sized such that they don't negatively affect it!
Component: Graphics → Theme
Product: Core → Firefox
QA Contact: thebes → theme
We deal with the height, but what about the overly bold font? Looks pretty bad if you compare the two screenshots.
Peter suggested it doesn't always happen; have you seen it too, Dão?
Looks slightly bolder with DirectWrite over here, but not like in the attached screenshot.
Component: Theme → Graphics
Product: Firefox → Core
QA Contact: theme → thebes
(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
That screenshot is from johnath's new machine, in case you want to see it in person, Joe!
I only want to block on the investigation of what's making this font apparently render bolder.
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
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
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).
I've found similar entry: Bug 601152
John, could you have a quick look? This sounds like WONTFIX to me but I'm not 100% sure.
Assignee: bas.schouten → jdaggett
Attached image Mirroring/Artifacts issue (deleted) —
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.
(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?
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.
Depends on: 610071
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/>).
The excessively bold rendering seems to happen only with D2D enabled.
Changed name of bug. Dao, fill bug for bold font. Thanks for fixing them!
Summary: Enabling DirectWrite causes increase of vertical size of Firefox Button → [Meta] Enabling DW/D2D causes changes of Firefox Button
Depends on: 594325
Depends on: 612853
Whiteboard: [soft blocker]
Whiteboard: [soft blocker] → [softblocker]
Depends on: 625029
blocking2.0: final+ → ---
No longer depends on: 625029
Keywords: regressionmeta
Hardware: x86 → All
Whiteboard: [softblocker]
Depends on: 625035
Depends on: 625029
Attached image Hardware acceleration off (deleted) —
Attachment #457276 - Attachment is obsolete: true
Attachment #457277 - Attachment is obsolete: true
Attached image Hardware acceleration on (deleted) —
Enabling HW acceleration causes increase of size: 1. On FXB's bottom by 1px, 2. On top of tabs by 1px.
Forgot to ask: Should I fill another bug for it? Or it is something else?
Not happening anymore.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: