626299 - font/text disappear

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[pal-moz]

Attachment: screenshot

regression from bug 622482

http://forums.mozillazine.org/viewtopic.php?p=10316669#p10316669

Comment 1

[Bas Schouten (:bas.schouten)]

John/Johnathan, do you have any idea why this would be different than most fonts for me manual glyph rasterization code which uses IDWriteGlyphRunAnalysis to get an alpha texture.

Comment 2

[pal-moz]

Attachment: screenshot

and hangeul in tab-title does not displayed.

URL : http://www.newscj.com/

Comment 3

[pal-moz]

Attachment: screenshot

on Google.

Comment 4

[Alice0775 White]

Attachment: reduced html (ameblo.jp)

This needs Japanese font "ＭＳ Ｐゴシック"

Comment 5

[Jonathan Kew [:jfkthame]]

An untested guess: could it be that this happens when the font is using embedded bitmaps rather than outlines? Try zooming the testcase to different sizes, and see if the disappearing text only happens at certain pixel sizes.

Comment 6

[Jonathan Kew [:jfkthame]]

I notice that the code in http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-d2d-surface.cpp (see line 3550 and following) fails to check the HRESULT return code from the various IDWriteFactory and IDWriteGlyphRunAnalysis methods used, such as CreateGlyphRunAnalysis and CreateAlphaTexture.

It would be good practice to check the HRESULT from *every* DW API that returns one, and return a suitable code (probably CAIRO_INT_STATUS_UNSUPPORTED) if any of them fail, so that we have a chance to fall back to an alternative path.

Comment 7

[John Daggett (:jtd)]

(In reply to comment #5)
> An untested guess: could it be that this happens when the font is using
> embedded bitmaps rather than outlines? Try zooming the testcase to different
> sizes, and see if the disappearing text only happens at certain pixel sizes.

I think this could be one factor, the reduced testcase by Alice0775 White renders differently at various zooms (first enlargement displays, second one doesn't).  But a simple waterfall test displays fine:

http://people.mozilla.org/~jdaggett/tests/msgothic-waterfall.html

Tested with:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre
Japanese Windows 7 with latest updates (including latest DirectWrite).

Comment 8

[pal-moz]

(In reply to comment #2)
> Created attachment 504343 [details]
> screenshot
> 
> and hangeul in tab-title does not displayed.
> 
> URL : http://www.newscj.com/

this issue is fine with non-aero (Basic) Windows theme.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: patch, add error checking in _cairo_dwrite_manual_show_glyphs_on_d2d_surface

This fixes the missing text, at least in my testing.

The specific issue here is that GetAlphaTextureBounds returns an empty rect in the case where a bitmap font size is being used (which is reasonable, as there are no subpixel-antialiased glyphs available); so we need to detect when that happens and return UNSUPPORTED rather than SUCCESS, so that we'll use a fallback code path and not believe rendering has been completed.

In addition, I've added error checks to a number of the Windows API calls here, as we shouldn't simply be assuming they'll fail.

Comment 11

[Jonathan Kew [:jfkthame]]

There's a tryserver build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-24059a1e66e6/, if anyone would like to confirm whether this fixes the issue for you.

Comment 12

[Jonathan Kew [:jfkthame]]

(In reply to comment #9)
> ....we shouldn't simply be assuming they'll fail.

Errr... I meant "they'll never fail", obviously.

Comment 13

[Bas Schouten (:bas.schouten)]

Comment on attachment 504401 [details] [diff] [review]
patch, add error checking in _cairo_dwrite_manual_show_glyphs_on_d2d_surface

While you're doing this could you add an error check for CreateGlyphRunAnalysis as that probably has a risk of failing?

On a sidenote why would it -not- be able to calculate those bounds for Asian fonts, there's nothing -forcing- it to do ClearType right? It can just fill in the same alpha value for each subpixel for those! Oh well, nice catch :-).

Comment 14

[Alice0775 White]

(In reply to comment #11)
> There's a tryserver build at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-24059a1e66e6/,
> if anyone would like to confirm whether this fixes the issue for you.
It fixed,

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to comment #13)
> While you're doing this could you add an error check for CreateGlyphRunAnalysis
> as that probably has a risk of failing?

Uh, I did. :) The test is after the delete[] statements, as we want those to happen even if we then take an early return.

Checked-in:
http://hg.mozilla.org/mozilla-central/rev/a66254dfa588

Comment 17

[cris]

This is fixed? so why I still have this problem? part of the title bar asian characters are still missing? 

try here

http://tieba.baidu.com/f?kw=%E4%BB%99%E8%91%AB&fr=tb0_search&ie=utf-8

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to comment #17)
> This is fixed? so why I still have this problem? part of the title bar asian
> characters are still missing? 
> 
> try here
> 
> http://tieba.baidu.com/f?kw=%E4%BB%99%E8%91%AB&fr=tb0_search&ie=utf-8

I don't see any missing characters when I visit that URL. Please provide a screenshot showing the problem you see, as well as the contents of about:support on your system, to help us understand what might be going wrong.

Comment 19

[cris]

Attachment: Titelbar still missing characters?

Application Basics

        Name
        Firefox

        Version
        4.0b10pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

  Extensions

        Name

        Version

        Enabled

        ID

        AVG Safe Search
        10.0.0.1178
        false
        {3f963a5b-e555-4543-90e2-c3908898db71}

        NoScript
        2.0.9.6rc1
        true
        {73a6fe31-595d-460b-a920-fcc0f8843232}

        FireGestures
        1.6b16
        true
        [e-mail]

        Adblock Plus
        1.3.5a2.2727
        true
        {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

  Modified Preferences

      Name

      Value

        accessibility.typeaheadfind
        true

        accessibility.typeaheadfind.flashBar
        0

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage
 

        browser.startup.homepage_override.buildID
        20110120030332

        browser.startup.homepage_override.mstone
        rv:2.0b10pre

        browser.tabs.warnOnClose
        false

        extensions.checkCompatibility.4.0b
        false

        extensions.lastAppVersion
        4.0b10pre

        font.language.group
        zh-CN

        font.name.monospace.zh-CN
        Microsoft YaHei

        font.name.sans-serif.zh-CN
        Microsoft YaHei

        font.name.serif.zh-CN
        Microsoft YaHei

        layers.accelerate-none
        true

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        128823

        print.print_printer
        Brother HL-2140 series

        print.printer_Brother_HL-2140_series.print_bgcolor
        false

        print.printer_Brother_HL-2140_series.print_bgimages
        false

        print.printer_Brother_HL-2140_series.print_command

        print.printer_Brother_HL-2140_series.print_downloadfonts
        false

        print.printer_Brother_HL-2140_series.print_edge_bottom
        0

        print.printer_Brother_HL-2140_series.print_edge_left
        0

        print.printer_Brother_HL-2140_series.print_edge_right
        0

        print.printer_Brother_HL-2140_series.print_edge_top
        0

        print.printer_Brother_HL-2140_series.print_evenpages
        true

        print.printer_Brother_HL-2140_series.print_footercenter

        print.printer_Brother_HL-2140_series.print_footerleft
        &PT

        print.printer_Brother_HL-2140_series.print_footerright
        &D

        print.printer_Brother_HL-2140_series.print_headercenter

        print.printer_Brother_HL-2140_series.print_headerleft
        &T

        print.printer_Brother_HL-2140_series.print_headerright
        &U

        print.printer_Brother_HL-2140_series.print_in_color
        true

        print.printer_Brother_HL-2140_series.print_margin_bottom
        0.5

        print.printer_Brother_HL-2140_series.print_margin_left
        0.5

        print.printer_Brother_HL-2140_series.print_margin_right
        0.5

        print.printer_Brother_HL-2140_series.print_margin_top
        0.5

        print.printer_Brother_HL-2140_series.print_oddpages
        true

        print.printer_Brother_HL-2140_series.print_orientation
        0

        print.printer_Brother_HL-2140_series.print_page_delay
        50

        print.printer_Brother_HL-2140_series.print_paper_data
        1

        print.printer_Brother_HL-2140_series.print_paper_height
        11.00

        print.printer_Brother_HL-2140_series.print_paper_size_type
        0

        print.printer_Brother_HL-2140_series.print_paper_size_unit
        0

        print.printer_Brother_HL-2140_series.print_paper_width
        8.50

        print.printer_Brother_HL-2140_series.print_reversed
        false

        print.printer_Brother_HL-2140_series.print_scaling
        1.00

        print.printer_Brother_HL-2140_series.print_shrink_to_fit
        true

        print.printer_Brother_HL-2140_series.print_to_file
        false

        print.printer_Brother_HL-2140_series.print_unwriteable_margin_bottom
        0

        print.printer_Brother_HL-2140_series.print_unwriteable_margin_left
        0

        print.printer_Brother_HL-2140_series.print_unwriteable_margin_right
        0

        print.printer_Brother_HL-2140_series.print_unwriteable_margin_top
        0

        privacy.sanitize.migrateFx3Prefs
        true

        security.warn_viewing_mixed
        false

  Graphics

        Adapter Description
        ATI Radeon HD 5700 Series

        Vendor ID
        1002

        Device ID
        68b8

        Adapter RAM
        1024

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.801.0.0

        Driver Date

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7600.20830)

        WebGL Renderer
        TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 20 2011 03:40:10)

        GPU Accelerated Windows
        1/1 Direct3D 10

Comment 20

[Reuben Morais [:reuben]]

(In reply to comment #18)
> I don't see any missing characters when I visit that URL.

You can check by looking at the tooltip:
http://dl.dropbox.com/u/10968786/fx4/tab_specialchars.png

Comment 21

[Reuben Morais [:reuben]]

(In reply to comment #20)

And yes, doesn't render the two first chars for me either on the link cris posted.

Comment 22

[Jonathan Kew [:jfkthame]]

Interesting - in the screenshot, I notice that the shadows of the missing glyphs are present, but the glyphs themselves are not drawn.

I suspect this may be a similar issue to the one already fixed, but on a slightly different codepath. Re-opening this bug for further investigation....

Comment 23

[pal-moz]

Attachment: screenshot

all fine here.

64 bit and/or ATI Graphics and/or used font issue ?


[my graphics]
Adapter Description : NVIDIA GeForce GTS 250
Vendor ID : 10de
Device ID : 0615
Adapter RAM : 1024
Adapter Drivers : nvd3dum nvwgf2um,nvwgf2um
Driver Version : 8.17.12.5896
Driver Date : 7-9-2010
Direct2D Enabled : true
DirectWrite Enabled : true (6.1.7600.16699)
WebGL Renderer : NVIDIA Corporation -- GeForce GTS 250/PCI/SSE2 -- 3.3.0
GPU Accelerated Windows : 1/1 Direct3D 10

Comment 24

[Jonathan Kew [:jfkthame]]

Aha - I can reproduce this by explicitly setting the Chinese font to Microsoft YaHei in Options. Will try to debug....

Comment 25

[Jonathan Kew [:jfkthame]]

Here's a reduced testcase that shows this problem for me. Note that on my system, the browser chrome is currently using MS PMincho for CJK characters in the tab titles; behavior may vary on different localized systems, depending on the default fonts.

data:text/html,<head><title>&#x4ed9;&#x846b;&#x5427;</title></head><body style="font: 12px MS PMincho">&#x4ed9;&#x846b;&#x5427;</body></html>

This should display the same three characters in the content and in the tab title; however, only the third one is rendered in the tab title; the first two are blank.

Comment 26

[Jonathan Kew [:jfkthame]]

Attachment: screenshot of the testcase from comment #25

Note that the tab title is missing the first two characters.

Comment 27

[Jonathan Kew [:jfkthame]]

It appears that this is caused by the presence of bitmap glyphs in the font being used; the _cairo_dwrite_manual_show_glyphs_on_d2d_surface function will fail to draw these, because GetAlphaTextureBounds() and CreateAlphaTexture() can't handle them with the DWRITE_TEXTURE_CLEARTYPE_3x1 option. (They'd be able to work with DWRITE_TEXTURE_ALIASED_1x1, but that's no use for the antialiased rendering we want here.)

The patch already landed here addressed this problem for the case where all the glyphs in the run being painted have bitmaps; in that case, we detect that GetAlphaTextureBounds() returns an empty rect, and return UNSUPPORTED.

However, things are not that simple, because it's possible for fonts to include bitmaps for *some* glyphs but not others (in any particular size). So if the glyph run we're trying to render includes *some* bitmap glyphs and some where only outlines are available, GetAlphaTextureBounds() will "succeed" and return a non-empty rect, and CreateAlphaTexture() will also "succeed", but the texture it returns will include images only for the outline glyphs, not the bitmaps.

I think we can fix this by ensuring that when bitmaps are present for the font size in use, the cairo_scaled_font is *not* allowed to have antialias_mode == CAIRO_ANTIALIAS_SUBPIXEL. It should be possible to do this, as we now have code in the gfxDWriteFont class to check for the presence of bitmaps.

Comment 28

[Jonathan Kew [:jfkthame]]

Attachment: patch 2 - avoid subpixel-AA when the font has bitmaps

We can resolve the problem by forcing the antialias mode to grayscale when the font has bitmaps, if it would otherwise have defaulted to subpixel. This restores the missing text in my testing.

The potential drawback of this is that any glyphs for which bitmaps are NOT present will be rendered with grayscale rather than subpixel AA; however, if we're getting a mix of bitmap and outline glyphs in the text, there's already some visual inconsistency going on, and I don't think forcing the outline glyphs to be grayscale in this case is a serious issue.

Comment 29

[John Daggett (:jtd)]

Comment on attachment 505824 [details] [diff] [review]
patch 2 - avoid subpixel-AA when the font has bitmaps

Looks fine, assuming that IE9 doesn't do subpixel aa on bitmap font glyphs (doesn't really make much sense...).

Comment 30

[Jonathan Kew [:jfkthame]]

http://hg.mozilla.org/mozilla-central/rev/4cfa1d632c93

It looks like IE9 actually forces all the glyphs (whether outline or bitmap) to be rendered as aliased (no smoothing at all) in this situation; we could do that as well, for uniformity, but I think we should consider that as a separate issue. This patch should fix the problem of missing text, at least.

Comment 31

[Steve Scott (pxbugz)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre