Closed Bug 626299 Opened 14 years ago Closed 14 years ago

font/text disappear

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: bugmozz, Assigned: jfkthame)

References

()

Details

(Keywords: regression, Whiteboard: [hardblocker][fx4-fixed-bugday])

Attachments

(9 files)

Attached image screenshot (deleted) β€”
regression from bug 622482

http://forums.mozillazine.org/viewtopic.php?p=10316669#p10316669
Blocks: 622482
blocking2.0: --- → ?
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.
Attached image screenshot (deleted) β€”
and hangeul in tab-title does not displayed.

URL : http://www.newscj.com/
Attached image screenshot (deleted) β€”
on Google.
Attached file reduced html (ameblo.jp) (deleted) β€”
This needs Japanese font "οΌ­οΌ³ Pゴシック"
Attachment #504354 - Attachment filename: hokuto-akira.htmt → hokuto-akira.html
Attachment #504354 - Attachment mime type: application/octet-stream → text/html
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 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.
(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).
(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.
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.
Attachment #504401 - Flags: review?(bas.schouten)
There's a tryserver build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jkew@mozilla.com-24059a1e66e6/, if anyone would like to confirm whether this fixes the issue for you.
(In reply to comment #9)
> ....we shouldn't simply be assuming they'll fail.

Errr... I meant "they'll never fail", obviously.
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 :-).
Attachment #504401 - Flags: review?(bas.schouten) → review+
(In reply to comment #11)
> There's a tryserver build at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jkew@mozilla.com-24059a1e66e6/,
> if anyone would like to confirm whether this fixes the issue for you.
It fixed,
blocking2.0: ? → betaN+
Assignee: nobody → jfkthame
Whiteboard: [hardblocker]
(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
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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
(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.
Attached image Titelbar still missing characters? (deleted) β€”
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
        firegestures@xuldev.org

        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
(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
(In reply to comment #20)

And yes, doesn't render the two first chars for me either on the link cris posted.
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....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached image screenshot (deleted) β€”
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
Aha - I can reproduce this by explicitly setting the Chinese font to Microsoft YaHei in Options. Will try to debug....
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.
Attached image screenshot of the testcase from comment #25 (deleted) β€”
Note that the tab title is missing the first two characters.
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.
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.
Attachment #505824 - Flags: review?(bas.schouten)
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...).
Attachment #505824 - Flags: review?(bas.schouten) → review+
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.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: