Originally, this issue was bug 1283739. But I guess that this might be
regression by bug 1464096.
Actually, reentrant code seems to be broken now, so I make it simple.
Differential Revision: https://phabricator.services.mozilla.com/D97266
If we don't disable hardware acceleration when we lose WebRender, we
will likely fallback to OpenGL compositing. This is not a supported
configuration. We already do this step if we decide against using
WebRender during configuration, but not if it was lost at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D97355
That avoids going all the way to the first continuation to call ResolveBidi on
it. This shaves a bunch of time when there are a lot of pages.
This is more problematic than it seems specially when there's no bidi, because
in the "bidi not enabled" case we never remove the flag, which is bad. When
bidi is actually enabled we usually have done the resolution already.
Differential Revision: https://phabricator.services.mozilla.com/D97358
This removes virtually all the time under ConsumedBSize. See the comment for
what ensures the correctness of the cache: Basically, we refresh the cache for
a frame continuation every time we reflow it, which means that when next
continuations go look for it it should be up-to-date (we rely on that already
because we're looking at the content rect).
Differential Revision: https://phabricator.services.mozilla.com/D97357
This avoids instancing twice the different storage type actors (legacy and resources). In order to keep current server tests working, a pref to force instancing legacy actors has been introduced.
Differential Revision: https://phabricator.services.mozilla.com/D97287
If an audio input is closed and then re-opened for the same AudioInputProcessing
listener, we end up re-using the same input packetizer. This would lead to the
data buffered in the input packetizer to be unaccounted for, inadvertently
triggering an assert.
This patch makes us clear the input packetizer when stopping an audio input such
that we have no state that can be unaccounted for.
Differential Revision: https://phabricator.services.mozilla.com/D97309
Prior to this patch the FramesProcessedEvent only exposed the number of frames
that had been verified non-silent. This meant there had to be a verifier and an
audio output hooked up to the audio input fed by the generator, for the event to
report any frames at all.
With this patch the FramesProcessedEvent reports the number of frames processed
by the fake audio thread, and the FramesVerifiedEvent the number of non-silent
frames seen by the verifier.
Differential Revision: https://phabricator.services.mozilla.com/D97307
It's better to have the control set on weither the RDD is enabled or not.
Additionally, RDD works on my Yoga ARM machine just fine.
Differential Revision: https://phabricator.services.mozilla.com/D96683
Now that launching the RDD process is fully asynchronous and no longer block the parent main thread, we can enable it on all platforms.
If we did fail to start it, we will not attempt again unless on Nightly.
Re-enable the RDD on Windows for ARM seeing that even if it did fail, it won't inconvenience the user anymore (other than the first video/audio element will take longer than usual to start)
Differential Revision: https://phabricator.services.mozilla.com/D96669
In bug 1674935 we encountered a situation where NotifyApzTransaction was called more than once on a scroll frame in one paint transaction, clearing the scroll updates before they should have been. In that bug I moved the NotifyApzTransaction calls to happen at the end of one transaction for the non-wr code path., but I left the wr code path alone to reduce risk becase we didn't have proof the same could happen with wr. In this bug I will change how the wr code path works to ensure that this problem cannot happen.
Differential Revision: https://phabricator.services.mozilla.com/D96165