c7c43406bfa941bb846e9861b8b8ed6d1e75df01: Backed out changeset 9e968a4d00bc (bug 1553011) for gtest crashes. CLOSED TREE
Narcis Beleuzu <nbeleuzu@mozilla.com> - Tue, 11 Jun 2019 10:32:25 +0300 - rev 478212
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Backed out changeset 9e968a4d00bc (bug 1553011) for gtest crashes. CLOSED TREE
01b51b19aae726e7ace236c0dfc1b36c750ff0b7: Bug 1555819 - Remove invalidated display items during PreProcessDisplayLists, since we might not merge their display list. r=miko
Matt Woodrow <mwoodrow@mozilla.com> - Tue, 11 Jun 2019 04:39:17 +0000 - rev 478211
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1555819 - Remove invalidated display items during PreProcessDisplayLists, since we might not merge their display list. r=miko Differential Revision: https://phabricator.services.mozilla.com/D33881
7a6259584cc87cea1229c4088f68e164b7d3516b: Bug 1547802 - Compute a single caret frame for the entire display list, and remove the option to invalidate frames during painting. r=miko,smaug
Matt Woodrow <mwoodrow@mozilla.com> - Tue, 11 Jun 2019 04:39:00 +0000 - rev 478210
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1547802 - Compute a single caret frame for the entire display list, and remove the option to invalidate frames during painting. r=miko,smaug Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments. This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building. Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint. Differential Revision: https://phabricator.services.mozilla.com/D33880
b4fdd901cceb779c06ba012991113b6c94714b5f: Backed out 9 changesets (bug 1554075) for reftest failures in Intervals.h and MP4Interval.h on a CLOSED TREE
Oana Pop Rus <opoprus@mozilla.com> - Tue, 11 Jun 2019 09:52:43 +0300 - rev 478209
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Backed out 9 changesets (bug 1554075) for reftest failures in Intervals.h and MP4Interval.h on a CLOSED TREE Backed out changeset d5543a60f833 (bug 1554075) Backed out changeset 1ea15f85c789 (bug 1554075) Backed out changeset a76688ee5b8a (bug 1554075) Backed out changeset 85482315a53c (bug 1554075) Backed out changeset c3f3e9e00279 (bug 1554075) Backed out changeset ac24ec2e0349 (bug 1554075) Backed out changeset b04fc8b0c07a (bug 1554075) Backed out changeset 2cce329d894d (bug 1554075) Backed out changeset 347b7b4eaab1 (bug 1554075)
edd8a9d9b629599d2b5dbd78d2bca9a14cc43daf: Bug 1554334 - P2. Assert that Once StaticPrefs setter is never called once initialized. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:32:59 +0000 - rev 478208
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554334 - P2. Assert that Once StaticPrefs setter is never called once initialized. r=njn Differential Revision: https://phabricator.services.mozilla.com/D33630
249d08cf3d7b5132b8e04e970091c02db5ea2648: Bug 1554334 - P1. Lazily initialize StaticPrefs with Once policy. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:32:45 +0000 - rev 478207
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554334 - P1. Lazily initialize StaticPrefs with Once policy. r=njn Rather than attempting to determine when the Once policy StaticPrefs should be set we initialize them when one of the getter gets called. They become immutable after that. In a future change we will prevent those values to ever be changed once they have been initialized. Differential Revision: https://phabricator.services.mozilla.com/D33440
a0de9c43eb2001c035ac9662688e1dd64eaee64c: Bug 1554559 - P3. Make Once StaticPrefs immutable once SharedPreferenceMap has been created. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:29:30 +0000 - rev 478206
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554559 - P3. Make Once StaticPrefs immutable once SharedPreferenceMap has been created. r=njn When we create the SharedPreferenceMap we store the value of the Once pref in it. All child processes will now read the Once pref from the read-only SharedPreferenceMap. This makes the Once prefs immutable once we start the first child process. Differential Revision: https://phabricator.services.mozilla.com/D33421
6a6477be5a1cfe749dd62520f68db8f0d8f4fa05: Bug 1554559 - P2. Add option for pref entry in SharedPrefMap to be skipped by iterator. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:29:26 +0000 - rev 478205
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554559 - P2. Add option for pref entry in SharedPrefMap to be skipped by iterator. r=njn This allows for an entry to not show in about:config. This will be used to store Once StaticPrefs once they become immutable. Differential Revision: https://phabricator.services.mozilla.com/D33420
bf610530422885d4b90cf021889f23e0a1afcde5: Bug 1554559 - P1. Test for invalid arguments. r=kershaw
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:29:23 +0000 - rev 478204
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554559 - P1. Test for invalid arguments. r=kershaw Will also silence static analysis in phabricator whenever a caller of this code is used. Differential Revision: https://phabricator.services.mozilla.com/D33419
9e968a4d00bc286fbb4842e9b113f9e264648911: Bug 1553011 - update import of Rust SDP parser - r=drno
Nico Grunbaum <na-g@nostrum.com> - Tue, 11 Jun 2019 06:01:42 +0000 - rev 478203
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1553011 - update import of Rust SDP parser - r=drno update import of Rust SDP parser Differential Revision: https://phabricator.services.mozilla.com/D31943
e334e63bfa2cdc80c6dee96ca34281c1184c2199: Bug 1557531 - Make preference Live. r=jgilbert
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 05:52:41 +0000 - rev 478202
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1557531 - Make preference Live. r=jgilbert The tests expects that setting the preference would lead to a different behaviour. However, this pref was set as once and as such immutable until the next restart. Differential Revision: https://phabricator.services.mozilla.com/D34282
30277c921db4253a7d068ddd54413bff6b746c4d: Bug 1557330 - Lowercase node.nodename in InactivePropertyHelper. r=rcaliman.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Tue, 11 Jun 2019 05:57:13 +0000 - rev 478201
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1557330 - Lowercase node.nodename in InactivePropertyHelper. r=rcaliman. Element.nodeName is usually all-caps, and we were testing lower cased version, which brought erroneous results. The test wasn't picking those errors because we were creating the element from a XHTML document, where Element.nodeName keep the casing used for their creation. The test is modified to deal with an HTML document instead. After the test was modified, I could see it was failing, and was then able to do the actual feature fix. Differential Revision: https://phabricator.services.mozilla.com/D34149
d5543a60f8335228f68cbaf760da511cf849b969: Bug 1554075 - Allow direct access of source buffer's data from demuxer, eliminating most copies. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:10:20 +0000 - rev 478200
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Allow direct access of source buffer's data from demuxer, eliminating most copies. r=jya 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
1ea15f85c7898c9fd412962d55ae83c565918f31: Bug 1554075 - Use BumpAllocator in MoofParser to speed up allocations. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:10:06 +0000 - rev 478199
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Use BumpAllocator in MoofParser to speed up allocations. r=jya 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
a76688ee5b8acca711f26aa6f68733ea46c51292: Bug 1554075 - Smooth out small gaps between MP4 samples' CTS across Moof boundaries. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:09:57 +0000 - rev 478198
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Smooth out small gaps between MP4 samples' CTS across Moof boundaries. r=jya 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
85482315a53c91ab96f1bdabf2cbdce7928da3ba: Bug 1554075 - Add fast path for IntervalSet::operator-= for removing a range that touches the front of a length 1 IntervalSet. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:09:43 +0000 - rev 478197
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Add fast path for IntervalSet::operator-= for removing a range that touches the front of a length 1 IntervalSet. r=jya 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
c3f3e9e0027999593b4fbf8cb0eddbe51d4673a1: Bug 1554075 - Add fast path to IntervalSet::Add(IntervalSet&) when adding a size 1 set. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:09:29 +0000 - rev 478196
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Add fast path to IntervalSet::Add(IntervalSet&) when adding a size 1 set. r=jya 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
ac24ec2e03498c00b14d4f78d8909881aa989dad: Bug 1554075 - Don't sort in IntervalSet::SetFuzz(). r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:09:15 +0000 - rev 478195
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Don't sort in IntervalSet::SetFuzz(). r=jya 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
b04fc8b0c07a9dcc379a25261da0140e7e687394: Bug 1554075 - Make ResourceQueue::GetOffsetAt() log(n). r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:09:01 +0000 - rev 478194
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Make ResourceQueue::GetOffsetAt() log(n). r=jya 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
2cce329d894d31b429e17484e200d70b28057874: Bug 1554075 - Don't store MP4 Box header; read it when needed. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 05:08:47 +0000 - rev 478193
Push 113412 by rgurzau@mozilla.com at Tue, 11 Jun 2019 21:39:14 +0000
Bug 1554075 - Don't store MP4 Box header; read it when needed. r=jya 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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip