1621007 - Text render broken in DX11 render mode

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect, P1)

Description

[copyliu]

Attachment: ss1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

1. set the render engine to Direct3D 11.
2. open https://jsfiddle.net/copyliu/waLrm9jv/2/ and click run
3. shows "TEST PAGE" text broken.

Actual results:

"TEST PAGE" in test page is broken, see screenshot : ss1.png

Expected results:

"TEST PAGE" in test page is rendered correct.

Comment 1

[copyliu]

this issue is only in D3D11, webrender seems ok

Comment 2

[Alice0775 White]

I can reproduce the issue on Direct3D 11 (Advanced Layers) Nightly75.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d2a4d549f9955412471054a5f5f92f7f1ad160a2&tochange=50d6aca7fe6978a1e373564737abd02b40050aed

Comment 3

[Boris Chiou [:boris]]

Hiro, I have to set up window environment and my desktop is in the office, so I cannot investigate this right now. Could you please reproduce this on Windows with Direct3D 11 (if you have windows platform at hand)? It seems "https://cdnjs.cloudflare.com/ajax/libs/parallax/3.1.0/parallax.min.js" uses preserve-3d anyway.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Attachment: A reduced test case

I could reproduce the issue on my Windows laptop.
A key factors is will-change:transform. Changes in ActiveLayerTracker in this commit changed something? Or it revealed a pre-existing issue?

https://hg.mozilla.org/integration/autoland/rev/50d6aca7fe6978a1e373564737abd02b40050aed

Comment 5

[Hiroyuki Ikezoe (:hiro)]

With the reduced test case in comment 4, I can see a different symptom on my Linux box without WebRender but I am pretty sure the root cause is the same. The symptom is that "TEST PAGE" isn't rendered. So, I suppose the problematic change in the commit is setting dirty rect and returning FullPrerender for elements which are far away from the display port. Probably we need to check whether the overflow area is within the display port or not.

Comment 6

[Boris Chiou [:boris]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)

With the reduced test case in comment 4, I can see a different symptom on my Linux box without WebRender but I am pretty sure the root cause is the same. The symptom is that "TEST PAGE" isn't rendered. So, I suppose the problematic change in the commit is setting dirty rect and returning FullPrerender for elements which are far away from the display port. Probably we need to check whether the overflow area is within the display port or not.

Thanks for checking this and providing the reduced test, Hiro. This is really helpful. This sounds reasonable, and I agree that we shouldn't always set the dirty rect for elements that are far away from the display port. Perhaps we should fall back this case to no prerender to avoid this issue.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Attachment: An interesting test case

This is another test case showing the problem (at least on my Linux box).
In this case, text-indent is 32725px, the dirty rect of the transformed box width is approximately 32767 in CSS pixel units. So to me there seems to be an int16 overflow issue in somewhere (I guess in font rendering backend). If I specify 32724px, the problem doesn't happen at all.

On a Windows 10 laptop, the boundary value is around 19000px.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

CCing jfkthame.

Comment 9

[Sotaro Ikeda [:sotaro]]

:boris, :hiro, are you working on this bug?

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I am afraid I don't too much. I just did put some facts I noticed yesterday. And now I noticed that the boundary, 32767, comes from gfx.max-texture-size

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Boris, FYI, you can see the issue on MacOSX with "layers.enable-tiles=false".

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Now I think this issue is another variant of bug 1144534.

Comment 13

[Jonathan Kew [:jfkthame]]

Trying the jsfiddle example on macOS (with layers.enable-tiles=false as per comment 11), I notice that the "fuzziness" gets worse as the magnitude of the text-indent is increased. E.g. at 5000px, it's barely noticeable; at 10000px, it's quite obviously fuzzy; at 20000px, it's like I'm wearing someone else's glasses; and at 40000px, the shape of the letters can only barely be seen at all.

So there's not an abrupt cut-off at a certain boundary, as we might expect from an integer overflow, but a gradual degradation. I think this indicates that the problem is caused by limited floating-point precision; as the absolute values of coordinates involved get larger, the precision of those coordinates is correspondingly reduced. (A lot of the graphics code uses single-precision floats; if it were double-precision everywhere, I suspect this issue would be much less severe, if noticeable at all.)

Comment 14

[Boris Chiou [:boris]]

Not working on this right now. At least I cannot debug this on Windows and Linux for now. (I can verify this later on mac but I still have no idea to fix this, due to the lack of the knowledge of web painting.) Please feel free to take a look at this if you have got a chance.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Ok, I will take this because I am the person who have got involved some amount of time.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

I am putting a link to comments by mattwoodrow about a proper way to fix this kind of large layer issues on transform animations with preserve-3d. https://chat.mozilla.org/#/room/#layout:mozilla.org/$SOi0PLIL7i2E2_c8C5qgLJh21UkppAeeKB23NPGCJgE

Comment 17

[Boris Chiou [:boris]]

Attachment: Bug 1621007 - Use enum class for PrerenderDecision.

Comment 18

[Boris Chiou [:boris]]

Attachment: Bug 1621007 - Rewrite the checking for PrerenderDecision and reset mAllowAsyncAnimation if needed in 3d context.

The basic idea is:
In the same 3d context (note: we use AutoPreserves3DContext to keep
this info), if any of the frames is not allowed to run compositor
animations, we have to force all of the frames not allowed.

In order to to this, we have to reset this flag (to false) when leaving the 3d
context. That's why we have to keep the info in Preserves3DContext, and reset
the flag in the destructor of AutoPreserves3DContext if needed.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/793c8aa4cdb6
Use enum class for PrerenderDecision. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/40aad8726a72
Rewrite the checking for PrerenderDecision and reset mAllowAsyncAnimation if needed in 3d context. r=mattwoodrow

Comment 20

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/793c8aa4cdb6
https://hg.mozilla.org/mozilla-central/rev/40aad8726a72

Comment 21

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue using Firefox 76.0a1 (20200309215254) on Windows 10x64.
The issue is verified fixed with Firefox 76.0b4 (20200412214314) on Windows 10x64.