Open Bug 786039 Opened 10 years ago Updated 6 years ago

[DirectWrite] horizontal ul display glitch with hardware acceleration

Categories

(Core :: Graphics, defect)

All
Windows
defect
Not set
normal

Tracking

()

People

(Reporter: mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(3 files)

13.14 KB, application/octet-stream
Details
14.15 KB, image/png
Details
11.24 KB, application/zip
Details
Attached file Test file
When I browse the test file joined in attachment, I have a glitch display problem when hardware acceleration is enable.
The same page is well displayed in firefox when hardware acceleration is disabled (restart in safe mode or on computer where acceleration is not supported).

The configuration detail when it fails :
Fisrt computer :
  Accélération graphique

        Description de la carte
        ATI Radeon HD 5700 Series

        ID du vendeur
        0x1002

        ID du périphérique
        0x68b8

        RAM de la carte
        1024

        Pilotes de la carte
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Version du pilote
        8.982.0.0

        Date du pilote
        7-27-2012

        Direct2D activé
        true

        DirectWrite activé
        true (6.1.7601.17789)

        Paramètres ClearType
        Paramètres ClearType introuvables

        Rendu WebGL
        Google Inc. -- ANGLE (ATI Radeon HD 5700 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.1041)

        Fenêtres avec accélération graphique
        1/1 Direct3D 10

        AzureBackend
        direct2d

Second computer :
  Accélération graphique

        Description de la carte
        Intel(R) HD Graphics

        ID du vendeur
        0x8086

        ID du périphérique
        0x0046

        RAM de la carte
        Unknown

        Pilotes de la carte
        igdumdx32 igd10umd32

        Version du pilote
        8.15.10.2622

        Date du pilote
        1-10-2012

        Direct2D activé
        true

        DirectWrite activé
        true (6.1.7601.17789)

        Paramètres ClearType
        Paramètres ClearType introuvables

        Rendu WebGL
        Google Inc. -- ANGLE (Intel(R) HD Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.1041)

        Fenêtres avec accélération graphique
        1/1 Direct3D 10

        AzureBackend
        direct2d


And when it works well :
A third computer :
  Accélération graphique

        Description de la carte
        Intel(R) HD Graphics Family

        ID du vendeur
        0x8086

        ID du périphérique
        0x0106

        RAM de la carte
        Unknown

        Pilotes de la carte
        igdumdx32 igd10umd32 igd10umd32

        Version du pilote
        8.15.10.2342

        Date du pilote
        3-25-2011

        Direct2D activé
        false

        DirectWrite activé
        false (0.0.0.0)

        Paramètres ClearType
        Paramètres ClearType introuvables

        Rendu WebGL
        Google Inc. -- ANGLE (Intel(R) HD Graphics Family) -- OpenGL ES 2.0 (ANGLE 1.0.0.1041)

        Fenêtres avec accélération graphique
        1/1 Direct3D 9



And as exemple is better to understand, I will join a screenshot of problem

I encounter this problem with firefox 14 and 15.
Attached image screenshot of problem
I found a regression since Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101112 Firefox/4.0b8pre
Anyway a reduced testcase would be great, maybe it's a known bug.

Regression range:

m-c
good=2010-11-11
bad=2010-11-12
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0f17e5f1eb01&tochange=35dfd6a0ace7
Component: General → Graphics
Product: Firefox → Core
Version: 15 Branch → Trunk
This is a very old regression. Loic, does this still reproduce for you?
Flags: needinfo?(epinal99-bugzilla2)
There is a weird behaviour.

It's not reproducible with the versions installed on my machine (release, beta, etc), but it's reproducible with every nightly I downloaded with Mozregression to find a working range, even the last ones.
Flags: needinfo?(epinal99-bugzilla2)
(In reply to Loic from comment #4)
> There is a weird behaviour.
> 
> It's not reproducible with the versions installed on my machine (release,
> beta, etc), but it's reproducible with every nightly I downloaded with
> Mozregression to find a working range, even the last ones.

Are you testing the local versions with a new profile? Mozregression creates a temporary profile with every build it tests.
Regression range: m-c [2010-08-13, 2010-08-14]
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d5e211bdd793&tochange=656d99ca089c
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → Windows
Hardware: x86_64 → All
Attached file Reduced testcase
Regression window force enabled Direct Write.
i.e.,
gfx.font_rendering.directwrite.enabled=true,
mozilla.widget.render-mode=6

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=260d768e55f4&tochange=64ebf70ed4a2

Suspect: 4365eabf7fb0	Jonathan Kew — bug 549190 - round dwrite font vertical metrics to improve rendering/spacing consistency. r=bas
Blocks: 549190
Summary: horizontal ul display glitch with hardware acceleration → [DirectWrite] horizontal ul display glitch with hardware acceleration
Flags: needinfo?(jfkthame)
Blocks: 1248191
Removing the testcase-wanted keyword considering the requested testcase was provided in comment 7.
Keywords: testcase-wanted
Looking at the original test file from comment 0, it appears that the CSS used is extremely fragile, and depends on the exact line-height metrics of the font being used. Adjusting the line-height of the <li> elements makes it possible to reproduce the "bug" on other platforms, or to cause an "inverse" version of the bug where the irregularity goes in the opposite direction; or by setting the value just right, the problem can be made to go away.

Alternatively, adjusting the padding-top value can also do similar things.

Moreover, with no adjustments to the styles in the test file, a similar problem appears even with DirectWrite disabled when running on a high-dpi display (where line metrics, because they snap to device pixels, can be finer-grained).

Changing which sans-serif font is used also affects the precise conditions for the "bug" to appear -- or for the design to work "cleanly" as intended.

All of which leads me to say -- this is an authoring problem. The page is making unsafe assumptions about the exact line metrics of the font being used and how they'll relate to other dimensions in the CSS. It's fragile and will not work reliably across all platforms and font configurations, and the change in bug 549190 just happened to expose this fragility.
Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.