4ef361678c07c388cdae9c807a7d6f3796ab20fa: Bug 1393441 - Disable test_bug293235.xul for on-going frequent intermittent failures; r=me,test-only
Geoff Brown <gbrown@mozilla.com> - Thu, 09 Nov 2017 09:33:03 -0700 - rev 695677
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1393441 - Disable test_bug293235.xul for on-going frequent intermittent failures; r=me,test-only
dbdadf5e2691bb6a159ffcefae97221110d3d533: Bug 1413442 - Disable test browser_inspector_highlighter-eyedropper-events.js on Windows for on-going frequent intermittent failures; r=me,test-only
Geoff Brown <gbrown@mozilla.com> - Thu, 09 Nov 2017 09:33:00 -0700 - rev 695676
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1413442 - Disable test browser_inspector_highlighter-eyedropper-events.js on Windows for on-going frequent intermittent failures; r=me,test-only
e47ee65540ba07f65f194908157834edd41a2272: Bug 1414632 - Prevent division by zero in webrtc::Merge::SignalScaling; r=jesup
Dan Minor <dminor@mozilla.com> - Wed, 08 Nov 2017 12:39:53 -0500 - rev 695675
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414632 - Prevent division by zero in webrtc::Merge::SignalScaling; r=jesup A zero input_length here would be caused by a decoder error in NetEqImpl::Decode(). Looking at the code in GetAudioInternal() which calls Decode() it appears that the intention is to continue processing even if no new audio data is decoded. Based on this, it seems safest to just skip muting in SignalScaling if the input_length is zero. The other potential cause of a division by zero here is if fs_mult_ is zero which should not normally happen. But there's no harm in checking for that as well. MozReview-Commit-ID: J0pd2wbjeZl
7d9324e2ab34946539be9f17d74f639aae5ba7e5: Don't reuse a back buffer after a swap if the content or surface changed (bug 1399692 part 9, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Sun, 05 Nov 2017 10:38:47 -0500 - rev 695674
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Don't reuse a back buffer after a swap if the content or surface changed (bug 1399692 part 9, r=bas) MozReview-Commit-ID: HGAxkeyESbc
76bf99decf0906f0a6a4ad99539fd40f97c4539f: Don't copy over regions that will be painted in this frame (bug 1399692 part 8, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Sat, 04 Nov 2017 14:52:31 -0400 - rev 695673
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Don't copy over regions that will be painted in this frame (bug 1399692 part 8, r=bas) We do the same in FinalizeFrame, so we should do it here. MozReview-Commit-ID: JTKDj8yrtI2
0fc2414f146d8f5d08c97e5b7eedb25c5632ab2d: Replay buffer commands on paint thread when OMTP is enabled (bug 1399692 part 7, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Thu, 26 Oct 2017 00:47:17 -0400 - rev 695672
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Replay buffer commands on paint thread when OMTP is enabled (bug 1399692 part 7, r=bas) This commit does the work of actually dispatching the recorded buffer operations to the paint thread, and removing some main thread asserts from TextureClient. MozReview-Commit-ID: CN3RoQPz9fP
f235b12eda6efe0bdec8e6590d813738f53ffe82: Record buffer operations to a struct for replaying on paint thread (bug 1399692 part 6, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Wed, 25 Oct 2017 10:20:49 -0400 - rev 695671
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Record buffer operations to a struct for replaying on paint thread (bug 1399692 part 6, r=bas) This commit adds a CapturedBufferState which is used to record all the operations that are necessary for preparing the buffers. The commands are then instantly executed to preserve the same behavior, but in the following commit they will be dispatched to the paint thread. Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made for sending to the paint thread. This complicates the code for AdjustTo as it can fail naturally and the buffer parameter changes are needed later in BeginPaint. So the code for AdjustTo is split up a bit to accomodate that. MozReview-Commit-ID: FwSwFay887o
467532fd5b7a2385ba0dbdb9201e28e8f2b4a583: Simplify copying the front buffer to the back buffer (bug 1399692 part 5, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 18:27:53 -0400 - rev 695670
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Simplify copying the front buffer to the back buffer (bug 1399692 part 5, r=bas) To sync the back buffer with the front buffer, we set the back buffer rect and rotation to the front buffer's, and then copy over the pixels that different. We used to do the updating of the rect and rotation before BeginPaint, but that isn't necessary and we can move it to be with the copying of pixels. MozReview-Commit-ID: HzBKvMZkn1
dce585be0737f3c9b6b241afb0851d85fb9453c9: Don't create back buffer for front buffer until we know what type to create. (bug 1399692 part 4, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 15:33:40 -0400 - rev 695669
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Don't create back buffer for front buffer until we know what type to create. (bug 1399692 part 4, r=bas) This commit is an optimization for double buffering that delays the creation of a back buffer until we know what kind of content type it needs to be. Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint, then in BeginPaint we could determine that we actually needed a different kind of buffer because the content changed type, and recreate it. This was needed because BeginPaint would copy the old front buffer to the buffer created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had determined we couldn't reuse the buffer, we would create a new one and copy that "temporary" back buffer over, and use the new one. This is unnecessary because we only need read access on that "temporary" back buffer, and so we can just use the current front buffer instead. This optimization only affects the double buffered case, and the single buffered or basic cases should remain the same. Note: Because we now need the front buffer for copying into the new back buffer, we cannot Clear() it away in some error cases. Note: The code in FinalizeFrame assumes that the back and front buffer have the same size. This was implicitly enforced before, and now needs to be explicitly enforced. This commit tries to preserve the exact same behavior, although the restriction should be removed as long as the back buffer is large enough for the visible region. MozReview-Commit-ID: 2hyrrUhA4zO
b971c1aa5a78c17d49d1d64389516437024be72a: Remove BufferContentType and add ValidBufferSize (bug 1399692 part 3, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 14:56:13 -0400 - rev 695668
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Remove BufferContentType and add ValidBufferSize (bug 1399692 part 3, r=bas) BufferContentType and BufferSizeOkFor make more sense as general functions for any RotatedBuffer, and this helps out in a later patch. MozReview-Commit-ID: EAVodvl4WTu
8ba8bda8521a6460b1213d2d0f14ebefc0a3e14a: Simplify the code for creating a new back buffer (bug 1399692 part 2, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 12:40:01 -0400 - rev 695667
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Simplify the code for creating a new back buffer (bug 1399692 part 2, r=bas) MozReview-Commit-ID: D28JNYWD9Uc
2c41a712dff22de4fb2bbfd7c5a418fbc3a26f11: Remove unneeded lambda capture in paint thread (bug 1399692 part 1, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Tue, 31 Oct 2017 01:55:24 -0400 - rev 695666
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Remove unneeded lambda capture in paint thread (bug 1399692 part 1, r=bas) MozReview-Commit-ID: 71X22PHRTRz
eadac792a9e36ff1bca0aad5edb790953d9525df: Bug 1414974 - Part 7: Remove nsGlobalWindow::Cast in favor of nsGlobalWindow{Inner,Outer}::Cast, r=smaug
Nika Layzell <nika@thelayzells.com> - Tue, 07 Nov 2017 11:40:21 -0500 - rev 695665
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 7: Remove nsGlobalWindow::Cast in favor of nsGlobalWindow{Inner,Outer}::Cast, r=smaug MozReview-Commit-ID: DCyyvQ0xKOj
cd4b951a1f54bdab2e8c5adfc1bf699e5cc6b10c: Bug 1414974 - Part 6: Change WebIDL bindings to refer to nsGlobalWindowInner rather than nsGlobalWindow, r=bz
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 17:52:14 -0500 - rev 695664
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 6: Change WebIDL bindings to refer to nsGlobalWindowInner rather than nsGlobalWindow, r=bz MozReview-Commit-ID: KbCpDFoWyTe
32a9df9f2b077cc08972c0fe2cef46c1d1e2a318: Bug 1414974 - Part 5: Rework nsWindowMemoryReporter to only examine inner windows, r=mccr8
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 14:48:02 -0500 - rev 695663
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 5: Rework nsWindowMemoryReporter to only examine inner windows, r=mccr8 MozReview-Commit-ID: 3be0C8OXSKo
ca6ed81bfc6789042be3b1947b7cc170dfef429f: Bug 1414974 - Part 4: Split WindowByIdTable into two separate tables for inner and outer windows, r=bz
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 17:59:12 -0500 - rev 695662
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 4: Split WindowByIdTable into two separate tables for inner and outer windows, r=bz MozReview-Commit-ID: LH3lKkFqTgG
5b48b5a65a462aa7f0f83d5c2acac2061d493509: Bug 1414974 - Part 3: Move Get{Inner,Outer}WindowWithId onto the specific subclasses, r=smaug
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 13:09:35 -0500 - rev 695661
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 3: Move Get{Inner,Outer}WindowWithId onto the specific subclasses, r=smaug These were originally exposed directly as static methods on nsGlobalWindow, but as they are clearly associated with either the inner or outer window, it makes more sense for them to be called as such. MozReview-Commit-ID: LFq8EfnhDlo
ff6e961b87dc1163c5efe35da2e334c6723a14e1: Bug 1414974 - Part 2: Switch many consumers to nsGlobalWindow{Inner,Outer}, r=smaug
Nika Layzell <nika@thelayzells.com> - Fri, 03 Nov 2017 18:25:38 -0400 - rev 695660
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 2: Switch many consumers to nsGlobalWindow{Inner,Outer}, r=smaug This is a large patch which tries to switch many of the external consumers of nsGlobalWindow to instead use the new Inner or Outer variants. MozReview-Commit-ID: 99648Lm46T5
e71c83eb16f68be36a10ebe1be36a282e0bbe458: Bug 1414974 - Part 1: Add the nsGlobalWindowInner/Outer classes, r=smaug
Nika Layzell <nika@thelayzells.com> - Fri, 03 Nov 2017 15:32:16 -0400 - rev 695659
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Bug 1414974 - Part 1: Add the nsGlobalWindowInner/Outer classes, r=smaug MozReview-Commit-ID: 5fLoC23MuNE
9ae742527820a5c0735dd17b0a2bbade6cc593ef: Fix DataSourceSurface mapping in GLReadTexImageHelper.cpp. (bug 1405390 part 6, r=jgilbert)
David Anderson <danderson@mozilla.com> - Thu, 09 Nov 2017 00:43:31 -0800 - rev 695658
Push 88496 by bmo:gl@mozilla.com at Thu, 09 Nov 2017 16:53:53 +0000
Fix DataSourceSurface mapping in GLReadTexImageHelper.cpp. (bug 1405390 part 6, r=jgilbert)
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip