aa2a510029838127f903e0e72fb5190ee427e5fa: Bug 1574327. Add a pref that we can use to disable d3d11 blacklist. r=aosmond
Jeff Muizelaar <jrmuizel@gmail.com> - Thu, 15 Aug 2019 22:39:18 +0000 - rev 488420
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1574327. Add a pref that we can use to disable d3d11 blacklist. r=aosmond We'll use this to enable WARP on CI. Differential Revision: https://phabricator.services.mozilla.com/D42221
76f8cb64876681e93d675465b48c4a6c8b84bc5d: Bug 1574263 - Switch to Tiny mode for DOM Mutationn Breakpoint reps r=Harald
David Walsh <dwalsh@mozilla.com> - Fri, 16 Aug 2019 00:56:14 +0000 - rev 488419
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1574263 - Switch to Tiny mode for DOM Mutationn Breakpoint reps r=Harald Differential Revision: https://phabricator.services.mozilla.com/D42177
03a1e5d857b555b7f400a94ca904786cba968c50: Bug 1491442 - Fix field order. r=fix CLOSED TREE
Markus Stange <mstange@themasta.com> - Thu, 15 Aug 2019 21:52:55 -0400 - rev 488418
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Fix field order. r=fix CLOSED TREE
0822612163d60c8c8deb17f0ab5c59de79b05a66: Bug 1491442 - Remove call to ReadBuffer. r=jgilbert
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:16:23 +0000 - rev 488417
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Remove call to ReadBuffer. r=jgilbert There's no other caller that sets ReadBuffer to anything else, and GL_BACK is the default for default framebuffers. Furthermore, this call triggers GL_INVALID_OPERATION errors when called on a non-default framebuffer. Differential Revision: https://phabricator.services.mozilla.com/D40551
ae86a277bd72b7a3c9b5e2ae40fcb74c33b796da: Bug 1491442 - Don't handle null render targets in this method. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:15:59 +0000 - rev 488416
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Don't handle null render targets in this method. r=mattwoodrow There's only one caller and it always passes a non-null render target. Differential Revision: https://phabricator.services.mozilla.com/D40550
706ff8a1badcd0c796e151b9e015bbfed0b20ddf: Bug 1491442 - Call SuspendAsyncCATransactions on window focus changes. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:15:34 +0000 - rev 488415
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Call SuspendAsyncCATransactions on window focus changes. r=mattwoodrow Without this, in windows with title bars, such as the bookmark library window, the title bar and the content would update at different times. The title bar paint is done as part of a main thread CoreAnimation transaction. However, by default, we don't get notified of all main thread CA transactions; our only notification mechanism is the updateLayer handler on the PixelHostingView, and that handler is only invoked (the layer is only displayed) if the layer has been marked as needing display. And by default, window focus changes do not mark random views' backing layers as needing display. Usually, what this means is that the window will be painted twice: Once in the main thread transaction, and then another time on the compositor thread once Gecko has noticed a state change and triggered its own composite in response. (Often, Gecko's compositor-side paint will actually happen *before* the main thread paint, because the main thread is often busy with repainting the system menu bar during window focus changes.) Such non-atomic window repaints look glitchy. Calling SuspendAsyncCATransactions will result in a call to updateLayer in the upcoming CoreAnimation transaction and lets us update the entire window in one atomic paint, and it will avoid updating the window early if the compositor thread gets ahead of the main thread. Differential Revision: https://phabricator.services.mozilla.com/D38759
e6e88a4fc6b95571d04db7841603bea7148df02f: Bug 1491442 - Disable window overlay drawing in the CoreAnimation path. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:15:10 +0000 - rev 488414
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Disable window overlay drawing in the CoreAnimation path. r=mattwoodrow Window overlay drawing was added as a workaround for the following: When our NSOpenGLContext covered the entire window, it would cover the titlebar contents and hide the window buttons and the title string. It would also not get anti-aliased rounded corner clipping. In windows that use CoreAnimation layers for the window frame, this is no longer a problem, because the CoreAnimation layer tree takes care of these effects: It applies rounded corner clipping to the window content layers, it puts the window buttons on top, and it also puts the title string on top if it is shown. So when we're using CoreAnimation, the existing code needs to be deactivated, otherwise we'd draw those things twice. Differential Revision: https://phabricator.services.mozilla.com/D38760
a5ba7777641703116a83c6b4bbea66308fb6e816: Bug 1491442 - Make sure to never trigger async CA transactions when the main thread might be resizing a window. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:14:47 +0000 - rev 488413
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Make sure to never trigger async CA transactions when the main thread might be resizing a window. r=mattwoodrow This avoids most window resizing glitches. Differential Revision: https://phabricator.services.mozilla.com/D40518
24dbae685801b451fba51d0e3788a821038c9321: Bug 1491442 - Support BasicCompositor OMTC rendering in the CoreAnimation path. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:14:22 +0000 - rev 488412
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Support BasicCompositor OMTC rendering in the CoreAnimation path. r=mattwoodrow Now CoreAnimation supports all rendering paths. The BasicCompositor OMTC path is used when hardware acceleration is disabled, for example in safe mode or when the user manually disabled it. Differential Revision: https://phabricator.services.mozilla.com/D38758
5aa5080461f8910b5b3e131f7164d236536aaf79: Bug 1491442 - Render accelerated windows into mContentLayer, using OMTC. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:13:52 +0000 - rev 488411
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Render accelerated windows into mContentLayer, using OMTC. r=mattwoodrow This makes windows that render using CompositorOGL or WebRender show content. Differential Revision: https://phabricator.services.mozilla.com/D40517
7711755e979e4ef6a37d0fec4bf3de41e8e4d148: Bug 1491442 - Make nsChildView create a NativeLayerRootCA and fill it with content when painting using BasicLayers (which used to go through drawRect). r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:13:35 +0000 - rev 488410
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Make nsChildView create a NativeLayerRootCA and fill it with content when painting using BasicLayers (which used to go through drawRect). r=mattwoodrow This makes context menus work. Regular windows are still blank at this point. This introduces a visual regression on 10.9: context menus and panels now no longer have a shadow. Only 10.10 and above support shadows on transparent windows that use CoreAnimation; 10.9 is not able to obtain the shadow shape on those types of windows. I think this is an acceptable regression to take. We want to use CoreAnimation for all window types because it simplifies the code (no need to handle two paths) and because it avoids expensive mode switches if we realize too late that a window we just opened is supposed to use CoreAnimation. Differential Revision: https://phabricator.services.mozilla.com/D40516
cf2547ffbfd4d065c691e00255ce8fdda5396cb3: Bug 1491442 - Add interfaces mozilla::layers::NativeLayerRoot and NativeLayer, and add CoreAnimation implementations NativeLayerRootCA and NativeLayerCA. r=jrmuizel
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:30:02 +0000 - rev 488409
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Add interfaces mozilla::layers::NativeLayerRoot and NativeLayer, and add CoreAnimation implementations NativeLayerRootCA and NativeLayerCA. r=jrmuizel NativeLayerRoot and NativeLayer allow building up a flat layer "tree" of sibling layers. They're created and manipulated with a synchronous-looking API, but any changes will only be applied to the underlying native layers when ApplyChanges() is called. This ensures that the modifications can be limited to run within a CoreAnimation transaction, and on a thread of the caller's choosing. In the near future I'm planning to have LayerManagerComposite create these layers. That's the reason for the pseudo-abstracted cross-platform C++ API: LayerManagerComposite can create and place the layers, and any painting into the layer surfaces will happen in the compositor implementations with platform-specific code. For now, the CoreAnimation implementation is the only implementation. I think the current API will let us use the same infrastructure for DirectComposite layers on Windows, but we'll likely need to make some API modifications once we attempt that. The classes are threadsafe; their methods can be called on any thread and the caller is responsible for sufficient synchronization. In reality, there are only two threads that would have a reason to use these layers: The compositor thread and the main thread. The main thread creates and destroys the NativeLayerRootCA, and sometimes it calls ApplyChanges, e.g. during window resizes. It also calls SetBackingScale. All other methods are usually only called on the compositor thread. Differential Revision: https://phabricator.services.mozilla.com/D26407
372c720b6ce81374cfca793c8ee4e0c9cade03b2: Bug 1491442 - When gfx.core-animation.enabled is true, use CoreAnimation for all windows and create an empty layer. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:13:19 +0000 - rev 488408
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - When gfx.core-animation.enabled is true, use CoreAnimation for all windows and create an empty layer. r=mattwoodrow This makes mPixelHostingView layer-backed, and that layer will be empty. This patch also causes all windows (including context menus, tooltips, arrow panels etc.) to use CoreAnimation layers for the window frame. This is achieved by calling setWantsLayer:YES on every window's content view. After this changeset, all windows will still be empty. Differential Revision: https://phabricator.services.mozilla.com/D38755
e89c3a6b2cd8eb8c8c328b86433765217ee7684e: Bug 1491442 - Disable all non-CoreAnimation rendering paths when gfx.core-animation.enabled is set. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:12:18 +0000 - rev 488407
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Disable all non-CoreAnimation rendering paths when gfx.core-animation.enabled is set. r=mattwoodrow This patch leaves you with empty windows everywhere. We will build the new rendering paths from the ground up in the upcoming patches. Differential Revision: https://phabricator.services.mozilla.com/D38754
9ffcdc648de567afa343e025298a2e2a424e7512: Bug 1491442 - If CoreAnimation is enabled, don't clip the TitlebarGradientView to rounded corners, and don't draw the title string on top of it. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:11:51 +0000 - rev 488406
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - If CoreAnimation is enabled, don't clip the TitlebarGradientView to rounded corners, and don't draw the title string on top of it. r=mattwoodrow Unlike what the old comment in its drawRect method says, this isn't actually dependent on the NSFullSizeContentViewWindowMask. Any window that uses CoreAnimation layers for its window frame will apply these effects automatically. Differential Revision: https://phabricator.services.mozilla.com/D38753
8e82722106c0d88adb7cbf322d764e72e7848838: Bug 1491442 - Remove -[ChildView isUsingOpenGL] and use mUsingOMTCompositor instead. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:11:27 +0000 - rev 488405
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Remove -[ChildView isUsingOpenGL] and use mUsingOMTCompositor instead. r=mattwoodrow We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change. Differential Revision: https://phabricator.services.mozilla.com/D38752
d66f54731eeb5e3117561152005e9a48a22c3838: Bug 1491442 - Add some documentation to mPixelHostingView. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:11:03 +0000 - rev 488404
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Add some documentation to mPixelHostingView. r=mattwoodrow Differential Revision: https://phabricator.services.mozilla.com/D38750
9216803cdf01a74cb7f66632e04dae97651f3913: Bug 1491442 - Fix comments that talk about BasicLayers but intend to say BasicCompositor. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:10:40 +0000 - rev 488403
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Fix comments that talk about BasicLayers but intend to say BasicCompositor. r=mattwoodrow BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing. Differential Revision: https://phabricator.services.mozilla.com/D38749
82b63cd1a2d378c8ffd461b27b24a07d758be866: Bug 1491442 - Fix up and document mNeedsGLUpdate locking semantics, and remove a stray semicolon. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:10:11 +0000 - rev 488402
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Fix up and document mNeedsGLUpdate locking semantics, and remove a stray semicolon. r=mattwoodrow Differential Revision: https://phabricator.services.mozilla.com/D38748
9dcce9060dac1eb0dd77b46433eb27d576311ca5: Bug 1491442 - Fold DoWidgetCleanup and DetachWidget into Compositor::Destroy. r=mattwoodrow
Markus Stange <mstange@themasta.com> - Fri, 16 Aug 2019 01:09:48 +0000 - rev 488401
Push 36443 by ccoroiu@mozilla.com at Fri, 16 Aug 2019 09:48:15 +0000
Bug 1491442 - Fold DoWidgetCleanup and DetachWidget into Compositor::Destroy. r=mattwoodrow Differential Revision: https://phabricator.services.mozilla.com/D40867
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip