1817455 - Misplaced fill in the profiler marker chart

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P2)

Description

[Markus Stange [:mstange]]

This was originally reported in https://github.com/firefox-devtools/profiler/issues/4477 .

Steps to reproduce:

1. Load https://share.firefox.dev/3k43pAZ
2. Look at the blue fill of the first box in the marker chart, the 300,000ms box next to the word DataStorageTimer
3. Try different page zoom levels.

Expected results:
The box should be filled completely and the fill shouldn't overflow.

Actual results:
Sometimes the fill is not filling the entire box, and sometimes it is overflowing, depending on zoom level.

Comment 1

[Bob Hood [:bhood]]

Lee, can you please have a look?

Note: I'm not able to reproduce on Win10/64 using Fx109 even up to +200% zoom, but I'm on SW-WR.

Comment 2

[Julien Wajsberg [:julienw]]

Running mozregression on my computer (linux, xwayland) gave this result: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26208f1c96fbfacd5c53bf6b856649adb0c29f43&tochange=b6982814673ac19bd0ef47f4d2ce905e4d6816e1

The regressing bug seems to be bug 1801584.

Comment 3

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

Set release status flags based on info from the regressing bug 1801584

Comment 4

[Lee Salzman [:lsalzman]]

Attachment: Bug 1817455 - Limit rect precision to avoid shader rounding diverging from path fallback. r?jrmuizel

Rectangle with large floating-point values can start to lose mantissa bits when transformed directly
by the vertex shader, pushed through the viewport transform, and then clipped later. OTOH, the path
fallback (WGR/AA-Stroke or Skia) does not stress floating-point precision as much, so generally
returns more correct results in these cases. This becomes noticeable when the same rectangle is
filled and then subsequently stroked, since the fill may use the rect shader, while the the stroke
will fall back to using a path.

To avoid hitting this issue, this checks if a rect's coordinate are outside as certain reasonable
limit, and if so, falls back to relying on path geometry to handle transform and clipping safely.
If within the limit, the shader precision loss doesn't noticeably impact the results so it is still
safe to use the fast-path.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f85246882e34
Limit rect precision to avoid shader rounding diverging from path fallback. r=gfx-reviewers,aosmond

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/f85246882e34

Comment 7

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

The patch landed in nightly and beta is affected.
:lsalzman, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox111 to wontfix.

For more information, please visit auto_nag documentation.

Comment 8

[Lee Salzman [:lsalzman]]

Comment on attachment 9318541 [details]
Bug 1817455 - Limit rect precision to avoid shader rounding diverging from path fallback. r?jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Potential visual artifacts in certain Canvas2D applications such as Firefox Profiler.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just disables a fast-path in certain situations that is causing some numerical accuracy issues.
• String changes made/needed:
• Is Android affected?: No

Comment 9

[Donal Meehan [:dmeehan]]

Comment on attachment 9318541 [details]
Bug 1817455 - Limit rect precision to avoid shader rounding diverging from path fallback. r?jrmuizel

Approved for 111.0b5

Comment 10

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1b32bdfd9ec6