1642901 - Large glyph disappears from PDF page when zooming in

Status: NEW

(Core :: Graphics: Text, defect)

Description

[Katelyn Gadd (:kael)]

Attachment: Chen_bonus_ch02.pdf

When viewing this PDF of an old print article, there is a large glyph behind the title on page one that is clearly legible at 'page fit' zoom for me. If I zoom in to 'page width' it completely disappears.

Comment 1

[Katelyn Gadd (:kael)]

Attachment: Page Fit

Comment 2

[Katelyn Gadd (:kael)]

Attachment: Page Width

I should note that the glyph remains visible for a brief period of time after zooming (1-2 frames?) and then disappears as the heading is re-typeset/re-rendered

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Brendan Dahl [:bdahl]]

I'm unable to reproduce on Ubuntu 20 with Firefox 77. What OS and version of FF are you using?

Comment 5

[Katelyn Gadd (:kael)]

Just reproduced using 78.0b9 (64-bit) on Windows 10

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Kenan]

Does this bug still exist?

I was not able to reproduce it (with Nightly on Win 10)

Comment 8

[Katelyn Gadd (:kael)]

Yes, it's still broken in 96.0b2

Comment 9

[Marco Castelluccio [:marco]]

(In reply to Katelyn Gadd (:kael) from comment #8)

Yes, it's still broken in 96.0b2

Could you try with Firefox Nightly?

Comment 10

[Marco Castelluccio [:marco]]

Katelyn, could you re-test using the latest Firefox release and Firefox Nightly?

Comment 11

[Katelyn Gadd (:kael)]

It's broken in 108.0b3 (64-bit) still, but I'll do a nightly test when I get a chance.

Comment 12

[Marco Castelluccio [:marco]]

None of us is able to reproduce (I tried on Linux, :calixte tried on Windows). Let's see if QA can reproduce.

Comment 13

[Katelyn Gadd (:kael)]

I've recently swapped out video cards as well, so it's not terribly likely to be hardware. Could be drivers, but I've also updated drivers quite a few times since the initial report.

It appears to be fixed in 109.0a1 (2022-11-23) (64-bit), I verified that it still reproduces on my 108.0b5 (64-bit) install after a reboot but not in Nightly.

Comment 14

[Marco Castelluccio [:marco]]

Oh, that's good. Could you try using mozregression to find out what fixed the bug?

Or maybe it could be related to your profile, can you reproduce in 108 with a clean profile too?

Comment 15

[Katelyn Gadd (:kael)]

Hmm, it doesn't repro on a clean profile. The problem is this pref:
gfx.font_rendering.cleartype_params.rendering_mode 5
This is the first time I've had a text rendering problem related to it. Really strange.

Comment 16

[Calixte Denizet (:calixte)]

I confirm that I can reproduce on windows 11 with gfx.font_rendering.cleartype_params.rendering_mode set to 5.
The H is rendered with zoom set to 137 but not at 138.
:jfkthame, could you have a look please ?

Comment 17

[Jonathan Kew [:jfkthame]]

I can't seem to reproduce this (on Win10), even with gfx.font_rendering.cleartype_params.rendering_mode set to 5; the large background glyph keeps rendering fine, all the way up to 1000%. There must be some other factor(s) also involved....

Comment 18

[Jonathan Kew [:jfkthame]]

I don't think this is a Layout issue; the rendering failure is somewhere on the Graphics side of things (or below that, e.g. in DirectWrite or drivers).

Comment 19

[Calixte Denizet (:calixte)]

If I set gfx.canvas.accelerated to true then it works correctly.

Comment 20

[Jonathan Kew [:jfkthame]]

Interesting; but on my system it's false and it still works, so there's more to it still.

When you don't set that pref, what backend does about:support indicate you're using?

Comment 21

[Calixte Denizet (:calixte)]

Attachment: support.json

Comment 22

[Katelyn Gadd (:kael)]

For me:

Compositing WebRender
Direct2D true
Target Frame Rate 120
DirectWrite true (10.0.19041.1566)
AzureCanvasBackend direct2d 1.1
AzureCanvasBackend (UI Process) skia
AzureContentBackend skia
AzureContentBackend (UI Process) skia
AzureFallbackCanvasBackend (UI Process) skia

GPU #1
Active Yes
Description NVIDIA GeForce RTX 3080 Ti
Vendor ID 0x10de
Device ID 0x2208
Driver Version 31.0.15.2686
Driver Date 11-8-2022

Comment 23

[Jonathan Kew [:jfkthame]]

I don't see any obvious clues there. Lee, do you have an idea why this would be failing for some people? I guess it's exceeding a glyph rasterization size limit somewhere, and then the fallback codepath isn't working, but I can't seem to reproduce.

Comment 24

[Katelyn Gadd (:kael)]

It could be because my monitor is high-DPI (set to 150%) so the internal rasterization is higher resolution?

Comment 25

[Jonathan Kew [:jfkthame]]

That would most likely affect the exact font size (or zoom amount) where it starts failing. But mine is also 150% (and I've tried zooming way, way in...), and it still doesn't fail for me.

Comment 26

[Lee Salzman [:lsalzman]]

If setting gpu canvas fixes it, then that points at Direct2D being the cause. By default Direct2D is how Canvas2D is implemented on Windows. With gpu canvas enabled, Skia gets used instead for rendering text - but still with DirectWrite, while bypassing Direct2D. So that means the bad news is that this is a bug in Direct2D that we would have to work around somehow if we could pin-point what extenuating circumstances lead to it happening, given that we can't fix it directly.

Comment 27

[Katelyn Gadd (:kael)]

The good news is that I don't think the cleartype params would normally get set to that at this point? The way it got set previously was by a cleartype tuner extension that no longer works. Though it's possible the OS-level cleartype settings might also override the cleartype mode used by Firefox...