…ity_binding. r=gw

The return value is not used at all.

Differential Revision: https://phabricator.services.mozilla.com/D63600

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/921116ca67a59fb323b74d1a610249c2448101d7

Differential Revision: https://phabricator.services.mozilla.com/D63601

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/737f4bc3afd3e823fd3f0e253388789a8c0d0299

Differential Revision: https://phabricator.services.mozilla.com/D63603

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/6b3af91a7ce6e5aee774cdde1c0dc5e2da7bebae

…mations on the compositor. r=gw,boris

Differential Revision: https://phabricator.services.mozilla.com/D63604

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/087518046b0c65aebc0c976bf2f736acf7cd4a89

Backed out changeset 28a2fba71977 (bug 1510030)
Backed out changeset 1700b3a416cd (bug 1510030)
Backed out changeset 087518046b0c (bug 1510030)
Backed out changeset 6b3af91a7ce6 (bug 1510030)
Backed out changeset 737f4bc3afd3 (bug 1510030)
Backed out changeset 921116ca67a5 (bug 1510030)

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/7fc17499b72099c0fa5d27f76c619229c01f2516

…ity_binding. r=gw

The return value is not used at all.

Differential Revision: https://phabricator.services.mozilla.com/D63600

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/b3dfa17c6305c657f8c3b3c95121c19f005d451c

Differential Revision: https://phabricator.services.mozilla.com/D63601

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/781cd96dd9a2d21922395d548d05e4f7ae5c155b

Differential Revision: https://phabricator.services.mozilla.com/D63603

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/b37ce2b87ac7b02a82a9caf6c45f7a4dea6d6017

…mations on the compositor. r=gw,boris

Differential Revision: https://phabricator.services.mozilla.com/D63604

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/a2be11cbe3f22a0b4f121df97045f560dca8ccb4

…html failures CLOSED TREE

Backed out changeset a14a131ca731 (bug 1510030)
Backed out changeset a75359516fec (bug 1510030)
Backed out changeset a2be11cbe3f2 (bug 1510030)
Backed out changeset b37ce2b87ac7 (bug 1510030)
Backed out changeset 781cd96dd9a2 (bug 1510030)
Backed out changeset b3dfa17c6305 (bug 1510030)

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/7d06c5f0f339c0016c764d49ebe6962b177a1e15

…ity_binding. r=gw

The return value is not used at all.

Differential Revision: https://phabricator.services.mozilla.com/D63600

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/fa80818e1861f83af3ee2d16de44aca23dd59294

Differential Revision: https://phabricator.services.mozilla.com/D63601

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/70a094437dfbacf8a110d015b32bdaa6936531c2

Differential Revision: https://phabricator.services.mozilla.com/D63603

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/42d17390bcca6e518624bddb755433277dd64ba4

…mations on the compositor. r=gw,boris

Differential Revision: https://phabricator.services.mozilla.com/D63604

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/9092c93a4ac6621e8fb255ae5b386046a0524c0a

…nts in webrender. r=lsalzman

Depends on D63893

Differential Revision: https://phabricator.services.mozilla.com/D64746

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/793e9dfa4b9fa40137cdf2a5d34c126d6cc9840d

…rop shadows in WebRender r=gfx-reviewers,kvark

Differential Revision: https://phabricator.services.mozilla.com/D63441

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/a9d8b62a399349559ceff12111f5d7fd3fab4acc

…AX_BLUR after scale factors are applied r=gfx-reviewers,nical

This was causing one of the large drop-shadow wrench reftests to timeout.
This is only a partial fix, as we should be checking the scale factors earlier on when sanitizing the
filter input. This will ensure we match what the non-WR backend is doing and will prevent overinflation.

Differential Revision: https://phabricator.services.mozilla.com/D64197

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/b7ab4c947688fab1ee8de2ef13a6033e2307d590

…ce. r=Bert

Previously, a native compositor surface was considered to be
completely opaque, or completely translucent. This is due to
a limitation in how alpha is handled in the DirectComposition
API level.

With this patch, each picture cache slice maintains both an
opaque and translucent native surface handle. Tiles are assigned
to one of those surfaces based on their current opacity.

This is a performance optimization in some cases, since:
 - Even if part of a cache is translucent, opaque tiles can
   still participate in occlusion at the compositor level.
 - If a tile is changing from opaque to translucent, it now
   invalidates only that tile, rather than the entire surface.

The primary benefit of this patch is that it allows compositor
surfaces to be drawn sliced in between the opaque surface and
any overlay / alpha tiles.

Differential Revision: https://phabricator.services.mozilla.com/D64495

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/6814870342efc284b2edec7c9aeb45240cb0fe09

… r=Bert

This patch fixes an oversight in part 5 of this patch series that
could result in an incorrect UV rect being used for an external
texture that uses a custom UV rect.

When the texture is an external texture, the UV rect is not known when
the external surface descriptor is created, because external textures
are not resolved until the lock() callback is invoked at the start of
the frame render. To handle this, query the texture resolver for the
UV rect if it's an external texture, otherwise use the default UV rect.

Differential Revision: https://phabricator.services.mozilla.com/D64687

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/8f267ed8f2e3d09ced8c665af0a6db3694197116

…instead. r=nical

A previous patch in this series introduced overlay tiles. However,
now that native surfaces exist for for the opaque and alpha tiles
within a slice, we can remove the overlay tiles array and add
these special tiles to the alpha surface.

Differential Revision: https://phabricator.services.mozilla.com/D64899

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/38b7f4761f5041a0e3b2326c2be37f98da509e21

The appveyor.yml change bumps it for windows. The macOS worker has the
rust version bumped out-of-band and the change to .taskcluster.yml just
updates the documentation.

Differential Revision: https://phabricator.services.mozilla.com/D64945

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/3ca5d53055d7f8665a29eed0b6fd6d992d834ce5

This patch improves the performance of compositor surfaces in
two ways:

(1) Ignore primitives behind the first compositor surface when
    determining whether a tile needs to be moved to the overlay
    (alpha) pass. This means WR only moves a tile to the alpha
    pass when it has primitives that overlap with the compositor
    surface bounding rect, and are ordered after that compositor
    surface. In practice, this means most tiles are able to
    remain in the fast (opaque) path. Typically, a small number
    of tiles that contain overlay video controls are moved to the
    alpha pass.

(2) Register the opaque compositor surfaces as potential occluders.
    This allows tiles that are completely covered by a compositor
    surface to be removed from the compositor visual tree, which
    helps both the simple and native compositor modes.

Between them, these optimizations typically mean that when watching
video in full-screen, nothing is composited except the video surface
itself, and some small region(s) where video overlay controls are
currently active.

Differential Revision: https://phabricator.services.mozilla.com/D64909

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/f6dc6b38288cfcb9f5f70932830d4a3d2b3759b2

…gw,aosmond

Differential Revision: https://phabricator.services.mozilla.com/D63434

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/12389e959ebb20da037a8800c2797b871afd29ea

Differential Revision: https://phabricator.services.mozilla.com/D65007

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/9cf4382f88826e7d458a1a9ec8b8470c9652cd83

…eyor CI. r=Bert

Differential Revision: https://phabricator.services.mozilla.com/D65164

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/438e07547213297357465701a32a7419d6ead18f

Rather than treating webrender::intern::UpdateList as a sequence of operations,
each of which might be an insertion or a removal, and using a side table to
supply extra data for insertions, it's simpler to segregate insertions and
removals into two separate vectors. This avoids the need for an enum whose
discriminant needs to be checked within the loop, and allows a few loops that
are only looking for one kind of operation to skip over the others entirely.

Ultimately, there should be no change in the order in which operations occur. In
practice, the old UpdateList always held a contiguous run of insertions,
followed by a run of removals (removals are consumed by apply_updates directly
after being generated by end_frame_and_get_pending_updates).

Differential Revision: https://phabricator.services.mozilla.com/D64444

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/06e238addde26dee65ee29f3cb676d7d47ff4e6e

Ensure that the image keys and image generations for external
compositor surfaces are included in the composite descriptor,
which is used to determine if a composite is required or can
be skipped.

Differential Revision: https://phabricator.services.mozilla.com/D65216

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/5f2a8eb4989755c3cf987738ea04034ac5bea896

Add support for a `fuzzy-range` keyword in reftest.list.
It is similar to `fuzzy` but it allows multiple pairs of
`max_difference, num_differences` numbers that introduce
multiple buckets of allowed differences.

For example, `fuzzy-range(5,100,20,10)` allows at most
100 pixels with a difference of at most 5, _plus_ an extra
10 pixels at most that have a difference more than 5 but
less than or equal to 20.
The total number of differing pixels allowed is thus 110,
but only if 100 of those differ by <= 5 and the remaining
10 by <= 20.
110 pixels with a difference <= 5 will still fail.
This is intentional to encourage tighter bounds in tests
where many pixels are slightly off and a few outliers are
off by a lot.

The number of parameters is arbitrary; longer lists can
get confusing so this change also introduces optional
support for writing `<=` in front of the max difference
and `*` in front of the max pixel count, eg.
`fuzzy-range(<=5,*100,<=20,*10)` (no spaces).

Any pixels that exceed the highest maximum will fail the
test, similar to `fuzzy`.

Steps tested:
1. the same tests fail in exactly the same way before and after;
2. reordered the `fuzzy` statements for raster_root_A/B/C to no longer
   be sorted by max difference, and verified that the tests pass/fail
   the same way;
   (then sort them again which is easier to understand);
3. tests using the new feature still fail when the ref no longer matches
   (deliberately broke the _ref version and verified test failed);

Differential Revision: https://phabricator.services.mozilla.com/D65247

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/8c07488c9a3f0a76e01ce34e060d071a2310612d

…r. r=gw

Differential Revision: https://phabricator.services.mozilla.com/D65391

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/010e798483903efee1caac88c01ba2b172d13c09

…or. r=Bert

Differential Revision: https://phabricator.services.mozilla.com/D65513

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/3c67e9f15e9361e595477f16e13e018b9aab35c0

…. r=Bert,sotaro

This patch refactors how external surfaces are stored in the
CompositeState structure. This is primarily to simplify integration
with native compositor mode, but also simplifies the Draw compositor
path.

Previously, the ResolvedExternalSurface struct contained information
that was used to rasterize the external surface (YUV planes etc) and
also the information to composite it (device rect, clip rect, z_id).

Now, ResolvedExternalSurface contains just the information required
to rasterize the external surface, while the compositing information
is handled by adding the external surface as a regular tile. This
makes it possible to unify how external surfaces are drawn, via the
common draw_tile_list method.

Differential Revision: https://phabricator.services.mozilla.com/D65269

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/4bbb79cbf9cc9efc7d599d1fe8d68bf620601fc9

…taro

This patch adds support for external compositor surfaces when
using native compositor mode.

Differential Revision: https://phabricator.services.mozilla.com/D65436

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/c3a689bf10e1dd2b1dc04fe0494584561bd8421b

…ender_task.rs:37 r=gw

Adding a repro-case reftest that asks for a 19996x5000 RenderTask (at
-p1), then fix it in analogy with the clamping to reasonable values that
happens for `NormalBorder`.

Differential Revision: https://phabricator.services.mozilla.com/D65660

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/14caf2826f00fc609f7fe55d8df14e7e08fd1ced