This patch fixes the off-by-one-pixel issue of Letterboxing. For
FindBar, it will be created when the user requests it and will be hidden
if the user close it after that. The problem of the original approach is
that it only observes the existance of the FindBar element but not the
fact that whether or not it is visible. So, it will miscalculate the
offset of FindBar after it has been created and closed.
For devtools, the original approach adds one pixel offset for the
separator. However, this one pixel offset is not required since there is
no extra separator outside the devtools iframe. So, we don't need that
and this patch removes this one pixel for the devtools.
Differential Revision: https://phabricator.services.mozilla.com/D34156
--HG--
extra : moz-landing-system : lando
UnsuppressAndInvalidate updates focus state among others, so it needs to be called even if paint suppression itself
isn't used. An example of a such case is when PresShell is created after Document's readyState is already Document::READYSTATE_COMPLETE.
Differential Revision: https://phabricator.services.mozilla.com/D34426
--HG--
extra : moz-landing-system : lando
A lot of the overhead in MoofParser::RebuildFragmentedIndex(BoxContext&) is
copying data into the BoxReader's storage. In the MSE case the underlying data
being read is actually buffered in memory, so we may be able to just read the
in-memory data directly, avoiding the copy.
Note that the data may not be stored in a single contiguous ResourceItem in the
SourceBufferResource's ResourQueue. If so, it's not as straightforward to hand
out a uint8_t* to the underlying data. So we just copy it in that case for
simplicity. In most cases, the data in a single MP4 box would be appended in a
single append, and so is likely to be in a single ResourceItem.
Differential Revision: https://phabricator.services.mozilla.com/D33877
--HG--
extra : moz-landing-system : lando
If you look down the call stacks inside MoofParser::RebuildFragmentedIndex(),
you'll see we spend most of the time inside BoxReader, e.g.:
https://perfht.ml/31b42u3
Each Box we create is read by a BoxReader, which makes a copy of the Box's
contents. We spend a bunch of time allocating the memory to store the copy on
the heap.
Since the allocations here are short lived (we delete the boxes at scope exit
of RebuildFragmentedIndex()), we can speed up the allocation by using a bump
allocator here. This means we hit malloc() and free() a lot less.
Note that Twitch only hits this allocator with allocations which are less
than 100 bytes. On YouTube we see a different pattern; there are still a lot
of allocations less than 100 bytes, but also a significant number which are
between 1500-1700 bytes.
The bump allocator lives on the BoxContext, so will be deallocated on scope
exit of MoofParser::RebuildFragmentedIndex().
Differential Revision: https://phabricator.services.mozilla.com/D33876
--HG--
extra : moz-landing-system : lando
Twitch is appending samples with small gaps between them, and the gaps span
Moof boundaries.
This means we end up have buffered ranges with lots of small gaps, and keeping
these up to date is expensive.
So remember the CTS of the last sample in each track, and pass that in when
parsing new Moofs. We can then remove the gaps, which makes our buffered
ranges simpler.
Note that Twitch often has a 1 microsecond gap between audio samples, but up to
1 millisecond gap between video samples; so we use a different threshold for
audio and video.
Differential Revision: https://phabricator.services.mozilla.com/D33875
--HG--
extra : moz-landing-system : lando
Twitch usually evicts data at the start of its buffered range, so handling this
case specially means we'll avoid the expensive general case.
Differential Revision: https://phabricator.services.mozilla.com/D33874
--HG--
extra : moz-landing-system : lando
When playing Twitch we can spend a lot of time in
TrackBuffersManager::InsertFrames() doing a
TimeIntervals::operator+=(TimeIntervals): https://perfht.ml/30CekTS
Twitch normally appends a range which touches the existing range. So we can
fast-path this case, and avoid the expensive reallocations, CheckedInt
comparisons and so forth in TimeIntervals::operator+=(TimeIntervals).
Note that this fast-path is already in place in
IntervalSet::operator+=(Interval), so we can just take that path when the size
of the incoming IntervalSet is 1.
Differential Revision: https://phabricator.services.mozilla.com/D33873
--HG--
extra : moz-landing-system : lando
This causes slowdowns in mozilla::TrackBuffersManager::Seek() due the time it
takes to sort: https://perfht.ml/30DqGLJ
Note the array of intervals should already be sorted, so we shouldn't need to
do the quicksort again.
We can also do the merging of intervals in place, rather than allocating a new
array to hold the normalized intervals.
Differential Revision: https://phabricator.services.mozilla.com/D33872
--HG--
extra : moz-landing-system : lando
The demuxer's low level byte reading abstraction is ResourceQueue::CopyData(),
but that's doing a linear scan through its list of ResourceItems in
GetOffsetAt() in order to find the ResourceItem in which the data to be read
lies. This sometimes shows up at the bottom of call stacks.
We could make this faster by doing a bisection search to find the ResourceItem
we need.
Differential Revision: https://phabricator.services.mozilla.com/D33871
--HG--
extra : moz-landing-system : lando
Profiling Twitch we see a significant amount of time at the bottom of our call
stacks in the MoofParser creating Box objects. Most of the time spend therein
is allocating and copying into an nsTArray. This is us copying the Box's header
into Box::mHeader. The reallocation and append are expensive. It turns out we
only use the box header in one place; when reporting the PSSH boxes up to EME.
So in the non-EME case, the storage of the Box header is a complete waste of
time and space.
So we can change the Box class to instead read the header from its storage when
we need to retrieve the complete PSSH boxes.
Differential Revision: https://phabricator.services.mozilla.com/D33870
--HG--
extra : moz-landing-system : lando
The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
When testing, the Preference behing a `Once` StaticPrefs should never get modified as this indicate that this StaticPrefs should have a `Live` policy instead.
This is placed behind the preferences.check.once.policy which will get enabled during automated testing.
Differential Revision: https://phabricator.services.mozilla.com/D34107
--HG--
extra : moz-landing-system : lando
This is intended to give a reasonable number that scales with the amount of
content in a website during page load, for scheduling purposes.
This effectively counts the amount of text connected to a document that isn't
likely to be inline style or script.
Potential improvements:
* Maybe have some more heuristics for hidden elements, like presence of the
`hidden` attribute?
* Maybe skip whitespace-only text? This does a pretty good job anyways because
whitespace nodes are usually pretty small (like a couple newlines and
spaces), so they don't add too much to the number. This could be done cheaply if
looking at sSpaceSharedString / sTabSharedString.
* Add some weight to some elements? Maybe images should have a fixed weight,
for example. Though you don't want 0x0 images and such to count... Maybe we
should add to this heuristic out of band when processing image loads or some
such.
* Handle shadow DOM and such better? Right now Shadow DOM and XBL are always
assumed visible as long as they're connected. You _can_ in theory do
something like stash a `<div>` inside a `<style>` element, attach a
ShadowRoot and such, and append a bunch of stuff inside. But I don't think
it's something we should be particularly worried about.
* Probably add some check to CharacterData::AppendText as well? Otherwise this
undercounts when loading big amount of text arrives via the network, for
example, but also I'm not sure we're optimizing for log files and such so it
might be ok.
In any case, this gives us a heuristic that we can iterate on later. This does a
pretty good job at representing the amount of content in the examples over here:
* https://faraday.basschouten.com/mozilla/executionorder/
For example for:
* https://faraday.basschouten.com/mozilla/executionorder/allinlinedual.html
You get an output like the following if you print the heuristic after each bind
operation (and de-duplicating them):
```
0
3 // Some whitespace in <head>
4 // Some whitespace in the <body>.
5
6
7
8
9
10
65547 // Actual content injected by the first script.
65548 // Some more whitespace.
131085 // Actual content injected by the second script.
131087 // Some more whitespace.
```
I'm not a fan of what clang-format has done to my code btw :)
Differential Revision: https://phabricator.services.mozilla.com/D34397
--HG--
extra : moz-landing-system : lando
Previously I rolled the malloc byte count into a total byte count for each zone but this may adversely affect GC scheduling (e.g. by triggering more non-incremental GCs because allocation volumes appear higher with this change). So that we can land this machinery without disturbing benchmarks too much, this patch splits out the new malloc memory accounting into a separate counter and uses the maxMallocBytes setting as the threshold (default value is 128MB vs 30MB for the GC heap threshold) and a growth factor of 2. This should make the behaviour closer to the original behaviour for now. We can go back and adjust the parameters later to obtain the desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D34181
The original float is not needed for layout, and thus there's no need to keep it
around.
This was presumably used by the old style system, but now it doesn't seem
useful, and is always `none`.
Differential Revision: https://phabricator.services.mozilla.com/D34442
--HG--
extra : moz-landing-system : lando
The tile cache is 352 bytes large and in the majority of cases picture primitives don't have one, so this saves a few KB of ram in typical pages reduces the likely hood of hitting OOM crashes while growing the primitives vector.
Differential Revision: https://phabricator.services.mozilla.com/D34346
--HG--
extra : moz-landing-system : lando
Hitting Ctrl+ArrowRight didn't have any effect on windows/linux.
The patch fixes this and add a test to make sure a user can
navigate from word to word using Ctrl (or Alt on OSX) and
Arrow Left/Right keys.
Differential Revision: https://phabricator.services.mozilla.com/D34312
--HG--
extra : moz-landing-system : lando
Currently, `HTMLEditor::GetSelectedElement()` is not used in mozilla-central
and mainly used for handling double clicks in the editor with its complicated
path. In most cases, users don't want double clicks to cause showing
property dialog in mail composer. Therefore, we must be able to stricter in
the complicated path.
This patch adds new check whether the selected range ends immediately before
a `<br>` element. If it's end at a `<br>` element, we shouldn't treat found
element as selected.
Note that when `<a href="...">` element is double-clicked, the element itself
is selected like `<img>` element. So, we don't need to worry about the case
which is that users probably want to update a link with double-clicking since
such case is handled by the first optimized path in the method.
Differential Revision: https://phabricator.services.mozilla.com/D34335
--HG--
extra : moz-landing-system : lando
