The PNG decoder lacks fast implementations for swizzling/unpacking
inside the library, and both PNG and WebP may need to perform
premultiplication due to the alpha channel. This patch adds a new filter
allowing us to take advantage of our accelerated implementations to
perform these transformations on their behalf.
Differential Revision: https://phabricator.services.mozilla.com/D46449
--HG--
extra : moz-landing-system : lando
Some filters can do the copy of the given data into the working buffer
as part of the filter operation. For those that cannot, we will just
copy the data first, and then advance the row.
Differential Revision: https://phabricator.services.mozilla.com/D46448
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
Avoid intermittent test failures on android.
The existing android assertion count was introduced by bug 1405550, to avoid
assertion count failures with stylo.
Differential Revision: https://phabricator.services.mozilla.com/D47792
--HG--
extra : moz-landing-system : lando
Change the displayed text of whitespace nodes in the inspector to "whitespace, and add a corresponding value to the inspector localized file. Also restyle the badge to match the scroll badge.
Differential Revision: https://phabricator.services.mozilla.com/D46388
--HG--
extra : moz-landing-system : lando
In addition, make sure the descriptor size stays in sync with the visible rect's size.
The descriptor's size stored in the resource cache is pretty much obsolete now, we should be able to clean it up and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D46803
--HG--
extra : moz-landing-system : lando
This logic is very 'mozill-central' specific and should live outside of mach
core if possible. Luckily we already have a concept of a 'pre_dispatch_handler'
that is meant for exactly this type of use case.
Differential Revision: https://phabricator.services.mozilla.com/D47668
--HG--
extra : moz-landing-system : lando
Also:
* Update the DefaultNurseryMaxBytes comment
* Fix the shell parameter handling.
Differential Revision: https://phabricator.services.mozilla.com/D47869
--HG--
extra : moz-landing-system : lando
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
The stream order does not depend on streams' finished state, so these calls are
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D47687
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
TrackID has been used to denote tracks that are part of MediaStreams in the
MediaStreamGraph. The TrackInfo::mTrackId IDs are no longer used in the
MediaStream APIs and as such it's not necessary that they have the type TrackID.
This patch changes TrackInfo::mTrackId to be of type uint32_t instead, as that
is the type of Mp4parseTrackInfo::track_id, which is assigned to
TrackInfo::mTrackId as the sole remaining non-static user.
Other users set a static trackId of `1` or `2`, and as such remain supported by
this change.
Differential Revision: https://phabricator.services.mozilla.com/D46763
--HG--
extra : moz-landing-system : lando
This patch introduces the concept of a "future ClientSource" to the
ClientManagerService. A "future ClientSource" is registered/removed
from the ClientManagerService by
ClientManager::{Register,Forget}FutureClientSource and is required
when a ClientInfo is initially created without a backing ClientSource.
As a result, the ClientManagerService can distinguish between a
ClientSourceParent* that has yet to register itself with the
ClientManagerService and a ClientSourceParent* that has already
both registered and removed itself from the ClientManagerService.
Differential Revision: https://phabricator.services.mozilla.com/D47592
--HG--
extra : moz-landing-system : lando
