Test the same features as the canvas-element reftests, for both a main-thread
OffscreenCanvas and in a worker.
Depends on D182567
Differential Revision: https://phabricator.services.mozilla.com/D182577
Surprisingly, this is sufficient to pass the existing WPT tests for fontVariantCaps.
(They only test setting and reading the attribute, but don't verify that it actually
has any effect on rendering!)
Rendering tests will be added in the next patch, along with hooking up the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D182566
While removing the .ini annotations for the other tests in this bug, I noticed
these ones (the only remaining annotations in the same directory) that seemed
to also be unnecessary. The tests pass on Try with these annotations removed,
so let's try removing them; and if needed, we can add back a more-specific
annotation if we discover intermittent fuzziness down the line.
Differential Revision: https://phabricator.services.mozilla.com/D182297
In these tests, the bounds of the red shape were technically already 1px
inwards from the bounds of the green shape (at the vertices at least), but that
still seems to create an opportunity for a little bit of red fringe along
antialiased diagonal lines. An additional pixel of "buffer" is sufficient to
avoid this fuzzy mismatch, since it ensures that the edge of the red shape is
at least a pixel inwards from the edge of the green shape along the whole
diagonal.
With that change, there are some remaining visually-imperceptible
(maxDifference of 1 in the green channel) fuzzy pixels. These ones are
unrelated to the red shape, and I'm adding annotations for them since they're
imperceptible and unrelated to what the test is trying to test.
We've got https://bugzilla.mozilla.org/show_bug.cgi?id=1840747 to track the
former issue (the red fringe), and we have
https://bugzilla.mozilla.org/show_bug.cgi?id=1840511 to track the latter issue
(off-by-1 in the green color channel).
Depends on D182295
Differential Revision: https://phabricator.services.mozilla.com/D182296
The barely-fuzzy pixels are visually imperceptible; they're just off-by-one in
a single color channel, along an antialiased edge of a transformed shape.
We have https://bugzilla.mozilla.org/show_bug.cgi?id=1840511 filed to track the
underlying behavior here. Since it's imperceptible and isn't what these tests
are trying to test for, let's adjust the fuzzy tolerance to avoid a spurious
failure.
Depends on D182294
Differential Revision: https://phabricator.services.mozilla.com/D182295
This is a trivial cosmetic fix to some WPTs, whose table-related CSS rules were
inadvertently targeting the dynamically-appended results table, which meant
that parts of the the test results were unreadable.
This patch is just putting all of the style rules for table parts behind a
`.target ` descendant selector. This lets those rules continue to match the
test content, without also matching the results table.
This fixes https://github.com/web-platform-tests/wpt/issues/40796
Differential Revision: https://phabricator.services.mozilla.com/D182406
This patch completes the implementation for close method.
By Close VideoDecoder algorithm [1], the error callback is invoked in a
task queued after Close, instead of being invoked directly in the Close.
With the change, the Decode-empty/corrupt-frame wpts need to be revised
since the error-callback is fired after flush, not before it.
By the spec [2], when decoding results an error, Close-VideoDecoder with
an EncodingError will be scheduled as the next task. In Close [3], the
Reset [4] will be performed first, and it will reject the pending flush
promises with the the given EncodingError (Close-VideoDecoder will run
before promise is resolved). Then, continue steps in Close [3], an error
callback with the EncodingError will be scheduled as the next task. That
is, according to the spec, the error callback is perform after the
flush's rejector (With EncodingError), so the wpts need to be revised.
[1] https://w3c.github.io/webcodecs/#close-videodecoder
[2] https://w3c.github.io/webcodecs/#dom-videodecoder-decode
[3] https://w3c.github.io/webcodecs/#close-videodecoder
[4] https://w3c.github.io/webcodecs/#reset-videodecoder
Depends on D180506
Differential Revision: https://phabricator.services.mozilla.com/D179515
> If decoding results in an error, queue a task to run the Close
> VideoDecoder algorithm with EncodingError and return
By the spec, in step 4-2 when running a control message for decode, if
the decode fails, the flush queued after that decode should be rejected
with a EncodingError, via Close algorithm, instead of AbortError.
Depends on D179583
Differential Revision: https://phabricator.services.mozilla.com/D180506
Likewise, we should also consider first baseline in the endmost line when
computing flex container last baseline.
Fixed the XXX comment by using logical coordinates. This is necessary to pass
flex-align-baseline-flex-004.html because it tests a vertical-rl flex container.
Differential Revision: https://phabricator.services.mozilla.com/D182432
This patch completes the implementation for close method.
By Close VideoDecoder algorithm [1], the error callback is invoked in a
task queued after Close, instead of being invoked directly in the Close.
With the change, the Decode-empty/corrupt-frame wpts need to be revised
since the error-callback is fired after flush, not before it.
By the spec [2], when decoding results an error, Close-VideoDecoder with
an EncodingError will be scheduled as the next task. In Close [3], the
Reset [4] will be performed first, and it will reject the pending flush
promises with the the given EncodingError (Close-VideoDecoder will run
before promise is resolved). Then, continue steps in Close [3], an error
callback with the EncodingError will be scheduled as the next task. That
is, according to the spec, the error callback is perform after the
flush's rejector (With EncodingError), so the wpts need to be revised.
[1] https://w3c.github.io/webcodecs/#close-videodecoder
[2] https://w3c.github.io/webcodecs/#dom-videodecoder-decode
[3] https://w3c.github.io/webcodecs/#close-videodecoder
[4] https://w3c.github.io/webcodecs/#reset-videodecoder
Depends on D180506
Differential Revision: https://phabricator.services.mozilla.com/D179515
> If decoding results in an error, queue a task to run the Close
> VideoDecoder algorithm with EncodingError and return
By the spec, in step 4-2 when running a control message for decode, if
the decode fails, the flush queued after that decode should be rejected
with a EncodingError, via Close algorithm, instead of AbortError.
Depends on D179583
Differential Revision: https://phabricator.services.mozilla.com/D180506
Tooru Fujisawa
Tom Schuster
Julien Cristau
Butkovits Atila
Robert Longson
Bas Schouten
Ziran Sun
Jonathan Kew
Gregory Pappas
Vincent Hilla
Henrik Skupin
Alex Ionescu
Julian Descottes
Masayuki Nakano
Noemi Erli
Daniel Holbert
Randell Jesup
Cosmin Sabou
Chun-Min Chang
Ting-Yu Lin
jijnyasa.goat
James Graham
Stanca Serban