Closed Bug 1621007 Opened 5 months ago Closed 4 months ago

Text render broken in DX11 render mode

Categories

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

73 Branch
Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- verified

People

(Reporter: copyliu, Assigned: boris)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

Attached image 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.

this issue is only in D3D11, webrender seems ok

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Graphics: Layers
Ever confirmed: true
Keywords: regression
OS: Unspecified → Windows
Product: Firefox → Core
Regressed by: 779598
Hardware: Unspecified → Desktop
Version: 74 Branch → 73 Branch
Flags: needinfo?(boris.chiou)

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.

Attached file 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

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.

(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.

Flags: needinfo?(boris.chiou)
Flags: needinfo?(sotaro.ikeda.g)
Priority: -- → P1

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.

CCing jfkthame.

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

Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(boris.chiou)

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

Flags: needinfo?(hikezoe.birchill)

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

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

See Also: → fuzzy-text

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.)

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.

Flags: needinfo?(boris.chiou)

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

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(sotaro.ikeda.g)

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

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.

Attachment #9134781 - Attachment description: Bug 1621007 - Rewrite the checking for PrerenderDecision and reset mAllowAsyncAnimation if any one is not allowed in 3d context. → Bug 1621007 - Rewrite the checking for PrerenderDecision and reset mAllowAsyncAnimation if needed in 3d context.
Pushed by bchiou@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Assignee: hikezoe.birchill → boris.chiou
Flags: qe-verify+

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.