Open Bug 1482193 Opened 3 years ago Updated 3 years ago

[wpt-sync] Sync PR 12382 - [PE] Allow blending for svg root

Categories

(Core :: SVG, enhancement, P4)

enhancement

Tracking

()

People

(Reporter: mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 12382 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/12382
Details from upstream follow.

Xianzhu Wang <wangxianzhu@chromium.org> wrote:
>  [PE] Allow blending for svg root
>  
>  Bug: 872437
>  Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
>  Change-Id: Idb0d69320ddfa2dcfe02e493cd117573618459d5
>  
>  Reviewed-on: https://chromium-review.googlesource.com/1169624
>  WPT-Export-Revision: 569cecd1ec178f2eccbb326d9a2c9ef08a04cf86
Component: web-platform-tests → SVG
Product: Testing → Core
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Whiteboard: [wptsync downstream error] → [wptsync downstream]
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Whiteboard: [wptsync downstream error] → [wptsync downstream]
Ran 1 tests
PASS   : 1
Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/762833d5e75d
[wpt PR 12382] - [PE] Allow blending for svg root etc., a=testonly
Backed out for failures on blending-svg-root.html

backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/e7aaefc49e5f08eef8e4cbe8dc08fdc00e1ade45

push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=b747faf1093a44b7901d05478db24efe4f57830f

failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=194129892&repo=mozilla-inbound&lineNumber=14909

11:28:01     INFO - TEST-START | /svg/render/reftests/blending-svg-root.html
11:28:01     INFO - PID 1098 | 1534357681434	Marionette	INFO	Testing http://web-platform.test:8000/svg/render/reftests/blending-svg-root.html == http://web-platform.test:8000/svg/render/reftests/blending-svg-root-ref.html
11:28:01     INFO - PID 1098 | 1534357681440	Marionette	DEBUG	[6442450945] Waiting for page load of http://web-platform.test:8000/svg/render/reftests/blending-svg-root-ref.html
11:28:01     INFO - PID 1098 | ++DOMWINDOW == 10 (0x11e82e000) [pid = 1102] [serial = 10] [outer = 0x10d33cc00]
11:28:01     INFO - PID 1098 | 1534357681463	Marionette	DEBUG	[6442450945] flushRendering false
11:28:01     INFO - PID 1098 | 1534357681479	Marionette	DEBUG	[6442450945] Waiting for page load of http://web-platform.test:8000/svg/render/reftests/blending-svg-root.html
11:28:01     INFO - PID 1098 | ++DOMWINDOW == 11 (0x11e82f800) [pid = 1102] [serial = 11] [outer = 0x10d33cc00]
11:28:01     INFO - PID 1098 | 1534357681502	Marionette	DEBUG	[6442450945] flushRendering true
11:28:01     INFO - PID 1098 | 1534357681528	Marionette	INFO	Found 1657 pixels different, maximum difference per channel 32
11:28:01     INFO - TEST-UNEXPECTED-FAIL | /svg/render/reftests/blending-svg-root.html | Testing http://web-platform.test:8000/svg/render/reftests/blending-svg-root.html == http://web-platform.test:8000/svg/render/reftests/blending-svg-root-ref.html
Flags: needinfo?(svoisen)
jwatt or emilio: Thoughts on this wpt sync failure? Though ... the differences seem to be in the text rendering, not in the SVG or related to blending.
Flags: needinfo?(svoisen)
Flags: needinfo?(jwatt)
Flags: needinfo?(emilio)
Huh, that's really weird. I thought this could've been about antialising or something, but this is just a block with a green background. Jonathan / Lee, have you seen some fuzziness like this before on such simple test-case?

Also, given this doesn't happen on Linux it may be worth to reland the test with a per-platform annotation. Probably James is the right person for that.
Flags: needinfo?(lsalzman)
Flags: needinfo?(jfkthame)
Flags: needinfo?(emilio)
I guess the presence of (non-'normal') mix-blend-mode is causing a change in layerization or something like that, which then affects the compositing of the antialiased text over the green background. I'm not sure exactly why it should be affected, as the mix-blend-mode property isn't applied to the text (or its background), but to another element -- but the fact that the block with mix-blend-mode is being composited onto the same background element may be enough to trigger the issue.

(FWIW, using a mix-blend-mode other than 'normal' creates a new stacking context, according to https://drafts.fxtf.org/compositing-1/#mix-blend-mode. Not sure exactly why that would affect the text, but perhaps it does.)

Aha.... here's an observation. The presence of mix-blend-mode is causing the text to be painted with grayscale rather than subpixel-AA. That's why there is a difference all around the edges of the glyphs. This is a lot easier to see if you take the text out of the <div> with the green background, so it's rendered on white.

This has nothing to do with the presence of SVG in the testcase, it's all about mix-blend-mode. Reduced example:

  <!DOCTYPE html>
  <div>Some Text</div>
  <div>&nbsp;</div>

renders "Some Text" with subpixel antialiasing, as expected. But:

  <!DOCTYPE html>
  <div>Some Text</div>
  <div style="mix-blend-mode: multiply">&nbsp;</div>

renders the text with grayscale AA.

I'm not sure whether this is expected, or if the text should be able to keep its subpixel AA even when some other element has mix-blend-mode applied. (FWIW, Chrome seems to show the same issue on this example.)
Flags: needinfo?(jfkthame)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
> Also, given this doesn't happen on Linux it may be worth to reland the test
> with a per-platform annotation.

We could, though I suspect it'd be fragile -- most likely the only reason it passes on Linux is that our test machines are configured in such a way that they never use subpixel-AA for this text (because of fontconfig setup, or because of the rendering options specified in their default serif font, or....). If that ever changes, I'd expect the test to start failing similarly on Linux.

Not sure offhand who maintains this test (it doesn't specify an author, afaics), but I suspect that adding -moz-osx-font-smoothing:grayscale would be a way to avoid the issue for us. (And Chrome would similarly benefit from -webkit-font-smoothing, I expect.)
The grayscale due to the getting stuffed in its own isolated layer would indeed be expected.
Flags: needinfo?(lsalzman)
(In reply to Jonathan Kew (:jfkthame) from comment #10)
> I suspect that adding -moz-osx-font-smoothing:grayscale would
> be a way to avoid the issue for us. (And Chrome would similarly benefit from
> -webkit-font-smoothing, I expect.)

James, can we go ahead and do that, and have the change upstreamed during the next sync? There's precedent for specifying webkit-font-smoothing in WPT at least:

https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/testing/web-platform/tests/resources/webidl2/coverage.html#163
Flags: needinfo?(jwatt) → needinfo?(james)
Oh, interesting.

So I would definietly support landing with that enabled and a comment to explain what's going on. When I tried enabling more CSS wpt reftests on Windows I didn notice that there were a lot of antialiasing problems that we weren't seeing on Linux, so I wonder if that's the same class of problems where Windows is using subpixel AA and Linux isn't. Is there some more generic solution here that doesn't just consist of adding CSS to every test where this is a problem?
Flags: needinfo?(james)
You need to log in before you can comment on or make changes to this bug.