f0901390f6a2b8bdb174e1a965d9977a34b68ccf: Bug 1556769, ensure UnsuppressAndInvalidate is called even if paint suppression isn't used, r=emilio
Olli Pettay <Olli.Pettay@helsinki.fi> - Tue, 11 Jun 2019 11:03:38 +0000 - rev 541052
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1556769, ensure UnsuppressAndInvalidate is called even if paint suppression isn't used, r=emilio 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
1a1b721ddf601392674d57df674b5ecaa3867214: 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 07:38:16 +0000 - rev 541051
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
bbee049da4d13a7a6b8b07132af89945a6af8678: Bug 1554075 - Use BumpAllocator in MoofParser to speed up allocations. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:38:03 +0000 - rev 541050
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
000e7c7094b28a327bee4bdeba1d5e69d057f6ba: Bug 1554075 - Smooth out small gaps between MP4 samples' CTS across Moof boundaries. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:37:54 +0000 - rev 541049
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
c042da4544fcfe3bc5de94e0c8a14d9c033def2f: 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 07:37:39 +0000 - rev 541048
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
f2a3e20dff914d817bf3793a80f15eca77e37c5f: 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 07:37:26 +0000 - rev 541047
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
3299b2df419a90549fab956b0187f97238b4e46f: Bug 1554075 - Don't sort in IntervalSet::SetFuzz(). r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:37:12 +0000 - rev 541046
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
c9ee6c0b151f6919cacf94d749c04f115ef0f802: Bug 1554075 - Make ResourceQueue::GetOffsetAt() log(n). r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:36:58 +0000 - rev 541045
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
82dcb120bc3fbc06289b307ff8e9af0818d88ed2: Bug 1554075 - Don't store MP4 Box header; read it when needed. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:36:44 +0000 - rev 541044
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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
42b5aa3fdc6134131f8609ae743727cb138888b4: Bug 1554075 - Move MediaDecoderStateMachine to its own thread pool. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 11 Jun 2019 07:36:29 +0000 - rev 541043
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1554075 - Move MediaDecoderStateMachine to its own thread pool. r=jya 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
a36380745805eba415f2c2098bbb6157c1734816: Bug 1557630 - P1. Simplify Preferences' getters code. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 06:11:50 +0000 - rev 541042
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1557630 - P1. Simplify Preferences' getters code. r=njn We use templates where appropriate instead. Differential Revision: https://phabricator.services.mozilla.com/D34272
e8a87ea5c95665ebe359e0ba335f228210110cd4: Bug 1556131 - P1. Potentially assert that a `Once` StaticPref stays in sync with underlying preference. r=njn
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Jun 2019 09:56:48 +0000 - rev 541041
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1556131 - P1. Potentially assert that a `Once` StaticPref stays in sync with underlying preference. r=njn 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
948aca54dd0b5ba6c3bbdc06e127a800c4317d61: Bug 1555133 - Add some heuristics about visible content in a document. r=bzbarsky
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 11 Jun 2019 10:00:46 +0000 - rev 541040
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1555133 - Add some heuristics about visible content in a document. r=bzbarsky 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
7d9eb0b9e39648624f1b7e448d7dc3310f75d0e6: Bug 1558370 - Correct disabling of test_arrowpanel.xul which redisables toolkit chrome tests on Android. r=emilio
Sebastian Hengst <archaeopteryx@coole-files.de> - Tue, 11 Jun 2019 09:50:26 +0000 - rev 541039
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1558370 - Correct disabling of test_arrowpanel.xul which redisables toolkit chrome tests on Android. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D34490
2e388d4237d0473f6e14f4218290d54857be84d6: Bug 1554158 - Always consume the enter key in UrlbarInput. r=mak
Dão Gottwald <dao@mozilla.com> - Tue, 11 Jun 2019 09:27:51 +0000 - rev 541038
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1554158 - Always consume the enter key in UrlbarInput. r=mak Differential Revision: https://phabricator.services.mozilla.com/D34268
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 +30000 +100000 tip