1526756 - Twitter video overlay is blurry in page content with WebRender enabled

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Kestrel]

Attachment: twitter-video-overlay-blurry.png

Twitter's video overlay is blurry when video is displayed in the page content. Fullscreen video is unaffected.

Example: https://twitter.com/firefox/status/1092835112331309056

OS: Ubuntu 18.10

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fdd03ab546fa01aa3705192b2445d7311d7ed997&tochange=e32dd08ec5db619b4c66dc1504a97e0abfc27a84

Regressed by Bug 1453935.

Comment 1

[Markus Stange [:mstange]]

I see this too. There's a translateZ(0px) transform, a scale(1) transform and a rounded clip in the ancestors of the blurry element. I haven't been able to reproduce this effect in a reduced testcase.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: A somewhat reduced test case

Toggling the 'transform' on the video element makes the text sharp. This strikes me as surprising.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: More reduced test case

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: More reduced test case

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

Attachment: More+ reduced test case

Cut away even more, based on attachment 9044436 [details]; thanks Jeff.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

When it uses an intermediate surface, the snapping isn't working as expected. Using the visible rect causes us to have 0 snap offsets, but it seems like we actually needed to snap to the unclipped primitive -- the actual clipping happens later for the rounded border. Let's see how many tests snapping to the primitive rect for blitted intermediate surfaces affects:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8af49c1057f4aa630a76c1165f7aac72580ebdf7

Comment 8

[Kestrel]

Attachment: Reddit blurry SVG test case

Another example in the wild with the same regressor is the main reddit logo on https://new.reddit.com. Reduced test case requires an SVG in a flex element with center alignment and a top/bottom border.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Captures from reduced test case and similar passing test case, v1

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

What this problem ultimately boils down to is thus:

1. Primitives have their own local rects and clip rects. They snap to the visible rect which is the intersection of its local rect and its clip rect.

2. Pictures have a local rect which is composed of the union of local rect of its children. A picture may apply its own more restrictive clip, which was not applied to the children. This means its visible rect does not match the union of the children.

Snapping to the visible rect is how we ensure that primitives are aligned relative to each other. Snapping to just the primitive's local rect is insufficient since its origin can be considered more or less arbitrary compared to what appears on the screen.

On to the speculation....

My belief is what we are missing then is an appropriate clip rect for snapping purposes. This should be some aggregate of the children's local clip rect, just as we do the calculation for the picture's clip rect. We can continue using the picture's clip rect for actual clipping, but for snapping we should use the aggregate clip rect.

This also provides some basis as to why my original patch in comment 7 "fixed" the problem. This is because in this case, the ideal aggregate clip rect for snapping is actually the same as the picture's local rect.

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

To expand further:

The aggregate clip rect to snap to should actually be the union of the set of primitive local rect's intersected with their local clip rect (e.g. the union of the visible rects).

The current picture local clip rect is calculated as the union of the bounding rects of the clusters within the picture:

https://searchfox.org/mozilla-central/rev/00f3836a87b844b5e4bc82f698c559b9966e4be2/gfx/wr/webrender/src/picture.rs#2790-2792,2799-2811,2828

The bounding rect of a cluster is calculated here:

https://searchfox.org/mozilla-central/rev/00f3836a87b844b5e4bc82f698c559b9966e4be2/gfx/wr/webrender/src/picture.rs#2132-2140

Which is, in fact, the visible rect of the primitive. Thus we should consider snapping to the primitive's local rect for a picture without intersecting with its clip rect. This is very close to the behaviour from the patch in comment 7, much more so than I had thought (or even intentioned ;)).

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1526756 - Snap brushes for pictures to the primitive instead of visible rect.

A picture can have its own unique clip which was not considered by its
children when calculating their visible rects. As a result, if a picture
clips its primitive rect for snapping purposes, it may produce a
different snapping offset than expected. We should instead just snap to
the primitive rect itself for the picture, since it is the union of the
visible rects that we snapped to for the children.

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c00a5b14e4e82021fde932f9ccb77548bf5c0db

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/00381acd841c
Snap brushes for pictures to the primitive instead of visible rect. r=kvark

Comment 15

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/00381acd841c

Comment 16

[Paul Stone]

It looks like this has regressed again, both on Twitter and the attached testcases. This is with WebRender on latest Nightly on Linux.

Comment 17

[Andrew Osmond [:aosmond] (he/him)]

(In reply to Paul Stone from comment #16)

It looks like this has regressed again, both on Twitter and the attached testcases. This is with WebRender on latest Nightly on Linux.

Yes there is a new bug open for this, bug 1540200.

Comment 18

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I successfully reproduced the issue on Firefox 67.0a1 2019-02-10 under Ubuntu 18.04 (x64) with WebRender and using the link from Comment 0 and the testcases.

The issue is no longer reproducible on Firefox 67.0b18 and latest Firefox Nightly 68.0a1 (2019-05-08).