1925413 - Dashed borders don't get snapped to device pixels at certain sizes/border-widths (resulting in a diagonal-looking edge from a bottom-right "notch", or fuzzy antialiased edges captured by Firefox's built-in screenshot tool)

Status: NEW

(Core :: Web Painting, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.
2. Look at the edges of the border dashes (ideally on a system with traditional 100% display-pixel-scaling. If you're on a HiDPI system, try different zoom levels, or try reducing your HiDPI to 100% pixel-scaling)

EXPECTED RESULTS:
The edges should be squared off.

ACTUAL RESULTS:
The dashes all have a "notch" missing on the bottom-right. See screenshot.

I think this manifests in rounding inconsistencies in some cases, where instead of a "notch", we snap-to-pixels one way or another non-deterministically. I think that's what's going on in bug 1903673, essentially.

I'm using Firefox Nightly 133.0a1 (2024-10-17) (64-bit) on Ubuntu 24.10.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of what I actually see (taken with OS screenshotting tool)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot scaled up 4x to make the notches easier to see

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot taken with Firefox's right-click screenshotting tool

Here's the result of Firefox's right-click|screenshot tool (which uses a different rendering path). The edges are antialiased instead of being "notched".

That antialiasing also seems like a bug, since we try to go out of our way to keep borders looking solid, I think (aside from dotted borders where we have to antialias along the curve to make it look curvy). I suspect the antialiasing is a manifestation of the same underlying issue, where we're placing these segment edges at fractional device-pixel-positions and then dealing with that as-best-we-can at drawing time.

Comment 4

[Daniel Holbert [:dholbert]]

Maybe this really belongs in Web Painting, given that it affects both actual on-screen rendering (webrender) and screenshots (which are non-webrender as I recall).

I think border-drawing/pixel-snapping is a web-painting thing, at least.

Comment 5

[Daniel Holbert [:dholbert]]

I can reproduce antialiased left/right dashes on the border segments going back quite a ways, pre-WebRender. That antialiasing started with this regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b6f7d0eb61b1878d3d906bd231edf225463ece3f&tochange=016e0f47e8ad66ba6eb11fe28958e3a69ef9e53d

Before that range, we draw solid segments (no antialiasing) in the attached testcase, but they're not nicely folded around the corners (i.e. we have a solid horizontal line at the top-left edge, rather than an "elbow" going around the corner).

In that range, I think bug 382721 would be where our behavior-change happened. Not sure if this is precisely a regression from that, but I'll mark it as depending-on-that-bug since this at least goes back that far.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: [not a bugfix] diagnostic patch to demonstrate intermittent failure due to this issue on Android with fission

Here's a diagnostic patch to illustrate this issue causing intermittent failures on Android. (I think it's caused by this issue, at least.)

This patch adds a simplified version of the reftest in bug 1903673, called flexbox-mbp-horiz-simpler-003v.xhtml, which in fact doesn't use flexbox at all but is just using that name to keep its place in the reftest ordering (which I suspect is necessary to hit the issue, though I'm not entirely sure).

Here's a failure on a try run where I had this patch applied (for task debug-geckoview-web-platform-tests-reftest-6, which happens to be the wpt-reftest-bucket where this test land on that platform):
https://treeherder.mozilla.org/logviewer?job_id=478766401&repo=try&lineNumber=6691

The reftest screenshot shows that the dashed border segments are crisply squared off (no antialiasing, no "notches"), but the testcase has them shifted 1px to the right, as compared to the reference case.

(The only difference between the testcase and reference case here is that the testcase has an empty child with a vertical-writing-mode -- that seems to be important, but I think it might be some sort of spooky-action-at-a-distance rather than an actual direct impact.)

Comment 7

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

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

For more information, please visit BugBot documentation.