searching for reviewer(sotaro)
5c5cdf8961e633f8217cf27a8b92a920f92996e5: Bug 1619882 [Wayland] Use WaylandDMABufSurface global lock instead of VAAPIFrameHolder at WaylandDMABUFSurfaceImage, r=sotaro
Martin Stransky <stransky@redhat.com> - Fri, 29 May 2020 15:22:07 +0000 - rev 533007
Push 37461 by ccoroiu@mozilla.com at Fri, 29 May 2020 21:46:31 +0000
Bug 1619882 [Wayland] Use WaylandDMABufSurface global lock instead of VAAPIFrameHolder at WaylandDMABUFSurfaceImage, r=sotaro VAAPIFrameHolder was moved to FFmpegVideoDecoder class and we use WaylandDMABufSurface global lock to keep surface reference until it's used. Differential Revision: https://phabricator.services.mozilla.com/D76691
f9f4bdf52d9b437a8a95484dd2563c4b45baabfd: Bug 1640009 - Hold a reference to VRManager singleton for the duration of the parent shutdown. r=sotaro
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 28 May 2020 07:32:57 +0000 - rev 532752
Push 37458 by nbeleuzu@mozilla.com at Thu, 28 May 2020 21:53:02 +0000
Bug 1640009 - Hold a reference to VRManager singleton for the duration of the parent shutdown. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D77205
837b1bff6998a5a34978777dac555a642fd203bd: Bug 1632443 - Fix pinch-zoom rendering when partial present is enabled. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Wed, 20 May 2020 05:33:06 +0000 - rev 530955
Push 37435 by apavel@mozilla.com at Wed, 20 May 2020 15:28:23 +0000
Bug 1632443 - Fix pinch-zoom rendering when partial present is enabled. r=sotaro WR currently disables picture caching during a pinch-zoom, if the native compositor is disabled (since there's no real performance gain to be had from caching tiles during a pinch-zoom). However, this code path was not returning a dirty rect to the caller code. For callers that take advantage of partial present, this meant the screen was assumed to have no changes, and so the swapbuffers is skipped incorrectly. Differential Revision: https://phabricator.services.mozilla.com/D76081
ae83a793e7c98d249e35645e9d7e95013bb5c279: Bug 1633432 - Don't detach SurfaceTextures from GL context on Pause(). r=sotaro,geckoview-reviewers,snorp,imanol
Jamie Nicol <jnicol@mozilla.com> - Fri, 15 May 2020 12:05:15 +0000 - rev 530260
Push 37420 by nerli@mozilla.com at Fri, 15 May 2020 21:52:36 +0000
Bug 1633432 - Don't detach SurfaceTextures from GL context on Pause(). r=sotaro,geckoview-reviewers,snorp,imanol In bug 1470348 we started to detach all SurfaceTextures from the current GL context in CompositorOGL::Pause(). This was required for VR, so that when the VR presentation was entered the SurfaceTextures could be attached to the VR context instead. When RenderCompositorEGL was implemented for webrender, we copied the call to detach from CompositorOGL. However, due to extra complexity in webrender's threading model, this is causing assertion failures. VR no longer relies upon the SurfaceTextures being detached when the compositor is paused, as it now uses its own SurfaceTexture set. Therefore we can remove the detach call from both CompositorOGL::Pause and RenderCompositorEGL::Pause. Differential Revision: https://phabricator.services.mozilla.com/D74832
c67a5c3491dfcfdc11dcfd644c26a8d7da67b2c4: Bug 1638010 [Wayland] Make WaylandDMABUFTextureData::BorrowDrawTarget() fail when underlying dmabuf surface is not locked, r=sotaro
Martin Stransky <stransky@redhat.com> - Fri, 15 May 2020 07:52:39 +0000 - rev 530236
Push 37420 by nerli@mozilla.com at Fri, 15 May 2020 21:52:36 +0000
Bug 1638010 [Wayland] Make WaylandDMABUFTextureData::BorrowDrawTarget() fail when underlying dmabuf surface is not locked, r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D75329
3e58ffac4bb8cfab0a2c5175872e227afd9e0a97: Bug 1635243. Only use WS_EX_LAYERED | WS_EX_TRANSPARENT on the compositor window on nightly for now. r=sotaro
Timothy Nikkel <tnikkel@gmail.com> - Tue, 05 May 2020 01:39:57 +0000 - rev 528002
Push 37380 by archaeopteryx@coole-files.de at Tue, 05 May 2020 09:46:21 +0000
Bug 1635243. Only use WS_EX_LAYERED | WS_EX_TRANSPARENT on the compositor window on nightly for now. r=sotaro We haven't shipped direct manipulation yet so we don't need these and they still cause blank windows for a very small number of users. Differential Revision: https://phabricator.services.mozilla.com/D73749
0d733ac48cab65b43776ea0da957b861f8eb34ba: Bug 1633343. Also use the style WS_EX_TRANSPARENT on the compositor window. r=sotaro
Timothy Nikkel <tnikkel@gmail.com> - Mon, 27 Apr 2020 13:27:07 +0000 - rev 526307
Push 37354 by shindli@mozilla.com at Tue, 28 Apr 2020 03:54:55 +0000
Bug 1633343. Also use the style WS_EX_TRANSPARENT on the compositor window. r=sotaro The original workaround given by Microsoft was both WS_EX_TRANSPARENT and WS_EX_LAYERED. In bug 1627505 we tried to just add WS_EX_LAYERED because it was all that was needed to fix that bug and we hoped it wouldn't re-introduce the blank window problem. But it did. So we may as well go with both flags as recommended by Microsoft. Differential Revision: https://phabricator.services.mozilla.com/D72598
3cbc071d09c7adf6433eefb8d6596561fcdc6681: Bug 1632357. Add a pref to disable adding the WS_EX_LAYERED style to the compositor window. r=sotaro
Timothy Nikkel <tnikkel@gmail.com> - Fri, 24 Apr 2020 08:58:16 +0000 - rev 525819
Push 37345 by csabou@mozilla.com at Fri, 24 Apr 2020 16:29:37 +0000
Bug 1632357. Add a pref to disable adding the WS_EX_LAYERED style to the compositor window. r=sotaro On older machines it creates a blank window and we only need the pref to direct manipulation (which hasn't landed yet and will be preffed off by default when it lands). Differential Revision: https://phabricator.services.mozilla.com/D72283
428d3ada2cb2f7d65e30d5c51f4c8633fdd6d38a: Bug 1632357. Add a pref to disable adding the WS_EX_LAYERED style to the compositor window. r=sotaro
Timothy Nikkel <tnikkel@gmail.com> - Fri, 24 Apr 2020 07:38:09 +0000 - rev 525811
Push 37345 by csabou@mozilla.com at Fri, 24 Apr 2020 16:29:37 +0000
Bug 1632357. Add a pref to disable adding the WS_EX_LAYERED style to the compositor window. r=sotaro On older machines it creates a blank window and we only need the pref to direct manipulation (which hasn't landed yet and will be preffed off by default when it lands). Differential Revision: https://phabricator.services.mozilla.com/D72283
20aad8c2fc424a4ef056386d3c54e18ca0c741d7: Bug 1631312. Move the check for UseWebRenderDCompWin(). r=sotaro
Jeff Muizelaar <jmuizelaar@mozilla.com> - Mon, 20 Apr 2020 06:11:52 +0000 - rev 524765
Push 37328 by apavel@mozilla.com at Mon, 20 Apr 2020 09:53:23 +0000
Bug 1631312. Move the check for UseWebRenderDCompWin(). r=sotaro Bug 1630629 moved the check UseWebRenderDCompWin before it had been initialized. This moves it below so that DirectComposition isn't disabled everywhere. Differential Revision: https://phabricator.services.mozilla.com/D71498
73632227ba00df584e8f6fcc1191e6dfa13fc5fd: Bug 1628901 - Fix panic caused by calling BeginDraw with empty dirty rect. r=sotaro
Glenn Watson <gw@intuitionlibrary.com> - Mon, 13 Apr 2020 00:37:19 +0000 - rev 523513
Push 37307 by ncsoregi@mozilla.com at Mon, 13 Apr 2020 15:49:18 +0000
Bug 1628901 - Fix panic caused by calling BeginDraw with empty dirty rect. r=sotaro Previously, it was possible for a tile that had a valid scroll root to have an empty valid (and dirty) rect due to the picture cache clip rect, in some situations. This could result in the tile not being tagged as off-screen, which means it is added to the queue of tiles to be updated. On most platforms this is benign, but the BeginDraw method of DirectComposition fails if the dirty rect is empty. This patch fixes the logic so that tiles that meet these conditions are correctly tagged as not visible, and skipped from update queue. Differential Revision: https://phabricator.services.mozilla.com/D70616
707b309fb85e305b0dd42cc6701b02aaa3de3273: Bug 1627505. Use WS_EX_LAYERED on the compositor window to prevent Direct Manipulation from finding it. r=sotaro
Timothy Nikkel <tnikkel@gmail.com> - Mon, 06 Apr 2020 18:25:28 +0000 - rev 522496
Push 37290 by aciure@mozilla.com at Tue, 07 Apr 2020 03:53:09 +0000
Bug 1627505. Use WS_EX_LAYERED on the compositor window to prevent Direct Manipulation from finding it. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D69765
2a815d6be90da35d285df65a6fc0f2369942f984: Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro
Kenny Levinsen <kl@kl.wtf> - Mon, 16 Mar 2020 23:24:39 +0000 - rev 519068
Push 37221 by opoprus@mozilla.com at Tue, 17 Mar 2020 09:36:40 +0000
Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change. Differential Revision: https://phabricator.services.mozilla.com/D65878
ef75f461147c5148755e505ed8b8c2d9ca20f856: Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro
Kenny Levinsen <kl@kl.wtf> - Mon, 16 Mar 2020 00:05:20 +0000 - rev 518883
Push 37218 by rmaries@mozilla.com at Mon, 16 Mar 2020 09:28:04 +0000
Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change. Differential Revision: https://phabricator.services.mozilla.com/D65878
8bc3cd786136a500f098c6f2604286696c796bb7: Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro
Kenny Levinsen <kl@kl.wtf> - Fri, 13 Mar 2020 16:04:36 +0000 - rev 518578
Push 37213 by shindli@mozilla.com at Fri, 13 Mar 2020 21:46:16 +0000
Bug 1614212 - Migrate global VsyncSource users correctly on frame rate change r=sotaro CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change. Differential Revision: https://phabricator.services.mozilla.com/D65878
2a28c94f3db2355dd50815d70f2ad6966839326c: Bug 1620147 - Fix virtual surface coords being outside bounds. r=Bert,sotaro
Glenn Watson <gw@intuitionlibrary.com> - Tue, 10 Mar 2020 02:17:35 +0000 - rev 517727
Push 37200 by malexandru@mozilla.com at Tue, 10 Mar 2020 09:44:45 +0000
Bug 1620147 - Fix virtual surface coords being outside bounds. r=Bert,sotaro This adds support for tracking and invalidating tiles based on a movable virtual offset. Differential Revision: https://phabricator.services.mozilla.com/D65687
c3a689bf10e1dd2b1dc04fe0494584561bd8421b: Bug 1579235 - Part 12 - Support native compositor surfaces. r=Bert,sotaro
Glenn Watson <gw@intuitionlibrary.com> - Thu, 05 Mar 2020 20:45:17 +0000 - rev 517126
Push 37186 by malexandru@mozilla.com at Fri, 06 Mar 2020 09:47:39 +0000
Bug 1579235 - Part 12 - Support native compositor surfaces. r=Bert,sotaro This patch adds support for external compositor surfaces when using native compositor mode. Differential Revision: https://phabricator.services.mozilla.com/D65436
4bbb79cbf9cc9efc7d599d1fe8d68bf620601fc9: Bug 1579235 - Part 11 - Refactor how external surfaces are composited. r=Bert,sotaro
Glenn Watson <gw@intuitionlibrary.com> - Thu, 05 Mar 2020 20:45:15 +0000 - rev 517123
Push 37186 by malexandru@mozilla.com at Fri, 06 Mar 2020 09:47:39 +0000
Bug 1579235 - Part 11 - Refactor how external surfaces are composited. r=Bert,sotaro This patch refactors how external surfaces are stored in the CompositeState structure. This is primarily to simplify integration with native compositor mode, but also simplifies the Draw compositor path. Previously, the ResolvedExternalSurface struct contained information that was used to rasterize the external surface (YUV planes etc) and also the information to composite it (device rect, clip rect, z_id). Now, ResolvedExternalSurface contains just the information required to rasterize the external surface, while the compositing information is handled by adding the external surface as a regular tile. This makes it possible to unify how external surfaces are drawn, via the common draw_tile_list method. Differential Revision: https://phabricator.services.mozilla.com/D65269
83c66ad3ea490076218308d346d50af80c1c2571: Bug 1617553 [Wayland] Use GL texture format instead of surface one for GL texture source, r=sotaro
Martin Stransky <stransky@redhat.com> - Mon, 24 Feb 2020 12:12:33 +0000 - rev 515271
Push 37155 by ccoroiu@mozilla.com at Tue, 25 Feb 2020 04:23:07 +0000
Bug 1617553 [Wayland] Use GL texture format instead of surface one for GL texture source, r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D63836
15ec792467141ac5561b87bddb80b38023a7d607: Bug 1616892 [Wayland] Use VAAPIFrameHolder at release callback, r=sotaro
Martin Stransky <stransky@redhat.com> - Fri, 21 Feb 2020 10:59:17 +0000 - rev 514988
Push 37148 by btara@mozilla.com at Fri, 21 Feb 2020 21:49:11 +0000
Bug 1616892 [Wayland] Use VAAPIFrameHolder at release callback, r=sotaro FFmpeg decoder needs to keep reference to more strucures for each frame so Bug 1616185 implements a VAAPIFrameHolder strucure and keeps the reference there. Let's use that also in WaylandDMABUFSurfaceImage. Differential Revision: https://phabricator.services.mozilla.com/D63513
4941724be9c2fd94c1e5df36ed90e42acc33f15f: Bug 1616590 [Wayland] Fix GL compositor to composite correctly NV12 textures generated by ffmpeg, r=sotaro
Martin Stransky <stransky@redhat.com> - Thu, 20 Feb 2020 14:08:25 +0000 - rev 514749
Push 37142 by nerli@mozilla.com at Thu, 20 Feb 2020 22:49:50 +0000
Bug 1616590 [Wayland] Fix GL compositor to composite correctly NV12 textures generated by ffmpeg, r=sotaro - Enable GL_TEXTURE_RECTANGLE_ARB only when the extension is supported - Switch Green and Alpha colors in NV12 shader when compositing on Wayland. Is's because vaExportSurfaceHandle() exports UV plane in DRM_FORMAT_GR88 format so we have to use R and G channels and not R and A as we have now. Differential Revision: https://phabricator.services.mozilla.com/D63349
e4383c8d1123da7eabe9c42042839cfc9eb2820d: Bug 1613364 [Wayland] Update gfx code to derived WaylandDMABufSurfaceRGBA class, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 12 Feb 2020 22:35:02 +0000 - rev 513637
Push 37118 by rmaries@mozilla.com at Thu, 13 Feb 2020 03:57:45 +0000
Bug 1613364 [Wayland] Update gfx code to derived WaylandDMABufSurfaceRGBA class, r=sotaro WaylandDMABufSurface/WaylandDMABufSurfaceRGBA uses textures interface instead of EGLImages so we need to update gfx code accordingly: - rename CreateEGLImage() -> CreateTexture() - rename ReleaseEGLImage() -> ReleaseTextures() - rename GetGLTexture() -> GetTexture() - rename WaylandDMABufSurface::CreateDMABufSurface() to WaylandDMABufSurfaceRGBA::CreateDMABufSurface() Differential Revision: https://phabricator.services.mozilla.com/D62005
cdab069b9ed9530c5bf018288dcf6ff69c175aa4: Bug 1613364 [Wayland] Update WaylandDMABUFTextureHostOGL and WaylandDMABUFTextureClientOGL to work with NV12 format, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 12 Feb 2020 22:34:59 +0000 - rev 513636
Push 37118 by rmaries@mozilla.com at Thu, 13 Feb 2020 03:57:45 +0000
Bug 1613364 [Wayland] Update WaylandDMABUFTextureHostOGL and WaylandDMABUFTextureClientOGL to work with NV12 format, r=sotaro - Update WaylandDMABUFTextureClientOGL to work with WaylandDMABufSurfaceRGBA which is used for GL/WebRender compositor with dmabuf texture backend. - Update WaylandDMABUFTextureHostOGL to work with both RGBA and NV12 surface formats. - Use GLTextureSource instead of EGLImageTextureSource as we need to store more than one texture there with NV12 and pass the textures there by CreateTextureSourceForPlane(). - Implement NV12 related function by WaylandDMABUFTextureHostOGL (color space, color range, sub-textures num). - Add NV12 implementation to PushResourceUpdates()/PushDisplayItems() for WebRender. Differential Revision: https://phabricator.services.mozilla.com/D62004
66cc62933540a2071ca024894ead927cd137c836: Bug 1613364 [Wayland] Update RenderWaylandDMABUFTextureHostOGL to work with NV12 texture format, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 12 Feb 2020 22:34:42 +0000 - rev 513635
Push 37118 by rmaries@mozilla.com at Thu, 13 Feb 2020 03:57:45 +0000
Bug 1613364 [Wayland] Update RenderWaylandDMABUFTextureHostOGL to work with NV12 texture format, r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D62003
640f0fc81c1f3f485b9b4748946611038eeb1e52: Bug 1613364 [Wayland] Update SurfaceDescriptorDMABuf to export YUV surfaces, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 12 Feb 2020 22:34:20 +0000 - rev 513632
Push 37118 by rmaries@mozilla.com at Thu, 13 Feb 2020 03:57:45 +0000
Bug 1613364 [Wayland] Update SurfaceDescriptorDMABuf to export YUV surfaces, r=sotaro We need to export more planes in SurfaceDescriptorDMABuf and also YUV color space. Differential Revision: https://phabricator.services.mozilla.com/D62000
174d5be06caa95bdc01153cdd8cff5152f406b6f: Bug 1608717 - Support per-tile clip (valid) region for native compositor implementations. r=sotaro,mstange
Glenn Watson <gw@intuitionlibrary.com> - Wed, 12 Feb 2020 04:27:15 +0000 - rev 513481
Push 37116 by rmaries@mozilla.com at Wed, 12 Feb 2020 20:57:45 +0000
Bug 1608717 - Support per-tile clip (valid) region for native compositor implementations. r=sotaro,mstange For Draw (non-native) and CA modes, we include the per-tile valid rect in the clip rect from the surface. For DC (non-virtual) mode, a per-tile clip rect is set on the visual for each tile, separate from the overall clip rect that is set on the surface visual. For DC (virtual) mode, the Trim API is used to remove pixels in the virtual tile area that are outside the valid / clipped region. Note: Although the valid rect is now applied in the native compositors, it's currently only based on the overall picture cache bounding rect. Thus, with this patch there isn't any noticeable performance improvement. Once this lands and is working correctly, the follow up patch to calculate a smaller valid region per-tile is a small amount of work. Differential Revision: https://phabricator.services.mozilla.com/D61424
be311b1bf072a0dd59fed4df979aafa506f73be6: Bug 1613358 [Wayland] Implement WaylandDMABUFSurfaceImage dmabuf image, r=sotaro
Martin Stransky <stransky@redhat.com> - Thu, 06 Feb 2020 15:15:02 +0000 - rev 512765
Push 37097 by csabou@mozilla.com at Thu, 06 Feb 2020 21:47:20 +0000
Bug 1613358 [Wayland] Implement WaylandDMABUFSurfaceImage dmabuf image, r=sotaro Implement WaylandDMABUFSurfaceImage which is backed by dma buf memory on Wayland and it holds decoded video images produced by ffmpeg va-api decoder. Differential Revision: https://phabricator.services.mozilla.com/D61678
6381c1f2aedca240ebbeb8feafb96f5b5977afce: Bug 1613358 [Wayland] Implement WaylandDMABUFSurfaceImage dmabuf image, r=sotaro
Martin Stransky <stransky@redhat.com> - Thu, 06 Feb 2020 12:10:57 +0000 - rev 512726
Push 37097 by csabou@mozilla.com at Thu, 06 Feb 2020 21:47:20 +0000
Bug 1613358 [Wayland] Implement WaylandDMABUFSurfaceImage dmabuf image, r=sotaro Implement WaylandDMABUFSurfaceImage which is backed by dma buf memory on Wayland and it holds decoded video images produced by ffmpeg va-api decoder. Differential Revision: https://phabricator.services.mozilla.com/D61678
032306d9ce87feb57f73bfebfcf29cf0e5a29e04: Bug 1613052 [Wayland] Don't release textures at WaylandDMABUFTextureHostOGL as they're owned by texture source, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 05 Feb 2020 08:31:08 +0000 - rev 512541
Push 37092 by apavel@mozilla.com at Wed, 05 Feb 2020 16:27:17 +0000
Bug 1613052 [Wayland] Don't release textures at WaylandDMABUFTextureHostOGL as they're owned by texture source, r=sotaro Depends on D61547 Differential Revision: https://phabricator.services.mozilla.com/D61548
a4c9db030d03e0f0b7e98a2f29a276747b48df6b: Bug 1613052 [Wayland] Use texture handle from WaylandDMABUFSurface directly at WebRender, r=sotaro
Martin Stransky <stransky@redhat.com> - Wed, 05 Feb 2020 08:31:01 +0000 - rev 512540
Push 37092 by apavel@mozilla.com at Wed, 05 Feb 2020 16:27:17 +0000
Bug 1613052 [Wayland] Use texture handle from WaylandDMABUFSurface directly at WebRender, r=sotaro Depends on D61546 Differential Revision: https://phabricator.services.mozilla.com/D61547
2546c38ebbc4f41611e13898675a7178de491321: Bug 1611357 - Update fuzziness for grid-track-intrinsic-sizing-002.html r=sotaro
Glenn Watson <gw@intuitionlibrary.com> - Fri, 24 Jan 2020 03:21:23 +0000 - rev 511601
Push 37053 by nbeleuzu@mozilla.com at Fri, 24 Jan 2020 21:46:30 +0000
Bug 1611357 - Update fuzziness for grid-track-intrinsic-sizing-002.html r=sotaro This test also has the same dashed border and occasional fuzziness that grid-track-intrinsic-sizing-003.html does with DC enabled. Differential Revision: https://phabricator.services.mozilla.com/D60947
b09849127a4f53a858ae0bfcba1343e5bd41458f: Bug 1608235 - [ANGLE] Validate `context` before use. r=sotaro
Jeff Gilbert <jgilbert@mozilla.com> - Thu, 23 Jan 2020 02:59:17 +0000 - rev 511289
Push 37047 by malexandru@mozilla.com at Thu, 23 Jan 2020 09:54:33 +0000
Bug 1608235 - [ANGLE] Validate `context` before use. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D60790
71ed65a465d2bcfcf8e02ab8779c6700754ccdb2: Bug 1610738 - Add primitive flag to specify a compositor surface is preferred r=sotaro
Glenn Watson <gw@intuitionlibrary.com> - Wed, 22 Jan 2020 08:31:19 +0000 - rev 511208
Push 37047 by malexandru@mozilla.com at Thu, 23 Jan 2020 09:54:33 +0000
Bug 1610738 - Add primitive flag to specify a compositor surface is preferred r=sotaro This allows calling code to specify whether a primitive would prefer to be promoted to a compositor surface and/or picture cache slice. This is a performance hint that can be used for large external primitives, such as videos and canvas elements. Differential Revision: https://phabricator.services.mozilla.com/D60637
f758f235dd70f1060dba771ccfd3cb91a9aaef20: Bug 1608741 - Part 2 - Disable dithering on gradient primitives. r=sotaro,nical
Glenn Watson <gw@intuitionlibrary.com> - Wed, 22 Jan 2020 01:24:14 +0000 - rev 511066
Push 37044 by opoprus@mozilla.com at Wed, 22 Jan 2020 09:48:59 +0000
Bug 1608741 - Part 2 - Disable dithering on gradient primitives. r=sotaro,nical There are a number of issues with the current gradient dithering implementation, that cause many test failures and also fuzziness rendering when enabling DirectComposition virtual surfaces. In particular, the dither result is dependent on the offset of the update rect within a render target. For now, this patch disables gradient dithering by default. This gives us: - A heap of new test PASS results (or reduced fuzziness). - Fixes a number of non-deterministic fuzziness bugs with DC. - Improves performance of gradient rendering by a reasonable amount. We can fix gradient dithering as a follow up, and re-enable if/when we find content that would benefit from it significantly (we may be able to improve gradients in other ways than dithering too). Differential Revision: https://phabricator.services.mozilla.com/D60460
994fc08c7acdeacbee0e567c98a810c19c655bb0: Bug 1608741 - Part 1 - Use nearest neighbor interpolation for DC surfaces. r=sotaro
Glenn Watson <gw@intuitionlibrary.com> - Mon, 20 Jan 2020 09:51:20 +0000 - rev 510844
Push 37036 by dvarga@mozilla.com at Tue, 21 Jan 2020 00:17:43 +0000
Bug 1608741 - Part 1 - Use nearest neighbor interpolation for DC surfaces. r=sotaro There's no need for bilinear interpolation of DC surfaces. This fixes a lot of the fuzziness issues when using virtual surfaces, so it makes sense to land it now while continuing to investigate the remaining issues. Differential Revision: https://phabricator.services.mozilla.com/D60383
bf297c03f0b7605ea3ea64320a3a4ce2b29f591f: Bug 1609913 - Fix memory leak of native compositor surfaces. r=sotaro
Glenn Watson <gw@intuitionlibrary.com> - Sun, 19 Jan 2020 22:14:58 +0000 - rev 510678
Push 37033 by aciure@mozilla.com at Mon, 20 Jan 2020 09:42:16 +0000
Bug 1609913 - Fix memory leak of native compositor surfaces. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D60379
c6b610d79104b1a8151b57ed207f0a0543b902cf: Bug 1608380 [Wayland] Provide dmabuf config for texture and webgl backends, r=sotaro
Martin Stransky <stransky@redhat.com> - Mon, 13 Jan 2020 13:30:26 +0000 - rev 509938
Push 37012 by apavel@mozilla.com at Tue, 14 Jan 2020 03:45:02 +0000
Bug 1608380 [Wayland] Provide dmabuf config for texture and webgl backends, r=sotaro We need to provide separated dmabuf configurations for WebGL and Texture backends as we want to enable dmabuf for WebGL only right now. Depends on D59487 Differential Revision: https://phabricator.services.mozilla.com/D59488
408f6c0f98146da1f540d5b6759e4d9a787db8ab: Bug 1608379 [Wayland] Don't use LOCAL_GL_TEXTURE_EXTERNAL on Wayland, r=sotaro
Martin Stransky <stransky@redhat.com> - Sat, 11 Jan 2020 17:50:20 +0000 - rev 509866
Push 37005 by nerli@mozilla.com at Sat, 11 Jan 2020 21:51:30 +0000
Bug 1608379 [Wayland] Don't use LOCAL_GL_TEXTURE_EXTERNAL on Wayland, r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D59480
0e1d591422956f3a8e9c372f31e3b3e413f73e65: Bug 1604412 - Give CompositorWidgetChild more window info r=sotaro
Chris Martin <cmartin@mozilla.com> - Wed, 08 Jan 2020 18:37:38 +0000 - rev 509764
Push 37004 by shindli@mozilla.com at Sat, 11 Jan 2020 09:48:29 +0000
Bug 1604412 - Give CompositorWidgetChild more window info r=sotaro CompositorWidgetChild is about to be responsible for creating, destroying, and presenting a shared buffer that CompositorWidgetParent will draw into. To do this, it will need the window handle, transparency mode changes, window size changes, and window size mode changes. Its creation is also about to become fallible, so it needs a separate initialization routine. Differential Revision: https://phabricator.services.mozilla.com/D57430
467a138c74bcc536a5282d67c92b0d0df93fee4f: Bug 1581868 - Make webrender schedule a frame immediately on resume. r=sotaro
Jamie Nicol <jnicol@mozilla.com> - Fri, 10 Jan 2020 02:01:30 +0000 - rev 509675
Push 37002 by ccoroiu@mozilla.com at Fri, 10 Jan 2020 21:49:10 +0000
Bug 1581868 - Make webrender schedule a frame immediately on resume. r=sotaro On webrender on android, parent-process pages (eg about:support) were not being rendered immediately after minimising then resuming the app, resulting in a black screen. The problem was that webrender believed the previous frame was still valid, and therefore that it did not need to render a new one. Content-process pages were unnaffected because we clear cached resources when the app is minimised, so we accidentally rendered a new frame on resumption. To fix this we always force a new frame to be rendered immediately on resumption. This uncovers a race condition which causes us to sometimes render frames at the wrong size when the window size has changed (for example when showing or hiding the keyboard), so that is also fixed. This also fixes a bug affecting fenix, where when opening a page in a new tab the portion of the screen where the keyboard used to be would remain black until the page had loaded. This no longer occurs because we force a composite as soon as the keyboard is hidden. Additionally, this patch reverts the original attempt at fixing this bug, as it is not necessary. Differential Revision: https://phabricator.services.mozilla.com/D59367
2991936a1598ea06a3c5ec90f3b9a5b63782780a: Bug 1604412 - Clarify purpose of PlatformCompositorWidgetDelegate r=sotaro
Chris Martin <cmartin@mozilla.com> - Wed, 08 Jan 2020 18:36:30 +0000 - rev 509611
Push 37000 by shindli@mozilla.com at Fri, 10 Jan 2020 05:03:08 +0000
Bug 1604412 - Clarify purpose of PlatformCompositorWidgetDelegate r=sotaro PlatformCompositorWidgetDelegate was meant to be a pure virtual base class for all the functions that nsWindow could call that would either go to an in-process compositor widget or an OMTC widget. By that definition, it does not seem like CompositorWidgetParent should be a subclass, since nsWindow cannot directly call its methods and currently CompositorWidgetParent has several "do nothing" implementations of the interface methods because they don't really belong. This changeset remedies this by refactoring CompositorWidgetParent so it is no longer an implementor of PlatformCompositorWidgetDelegate. Now the only implementors are CompositorWidgetChild and InProcessWin- CompositorWidget, which makes sense because they are both directly called through the nsWindow delegate. It also eliminates some of the methods that seem like they don't belong in PlatformCompositorWidgetDelegate. Differential Revision: https://phabricator.services.mozilla.com/D57429
f196f5e7ee66294daa0366aca3a45acc4c2c30fb: Bug 1604412 - Duplicate WinCompositorWidget logic into subclasses r=sotaro
Chris Martin <cmartin@mozilla.com> - Wed, 08 Jan 2020 18:35:22 +0000 - rev 509400
Push 36995 by apavel@mozilla.com at Wed, 08 Jan 2020 21:56:06 +0000
Bug 1604412 - Duplicate WinCompositorWidget logic into subclasses r=sotaro This looks like a large change, but it's really just moving stuff around. It takes the logic in WinCompositorWidget and duplicates it into its only 2 subclasses: InProcessWinCompositorWidget and CompositorWidgetParent. This is because CompositorWidgetParent is about to change *a lot*, but InProcessWinCompositorWidget will basically stay the same. This is an easy way to verify that I don't accidently break InProcessWinCompositorWidget. Differential Revision: https://phabricator.services.mozilla.com/D57428
e9d191b5eb8a78b117f55c0dd6993cb0d136c7c8: Bug 1606685 - Support empty tiles within compositor surfaces. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Wed, 08 Jan 2020 04:57:31 +0000 - rev 509301
Push 36994 by ccoroiu@mozilla.com at Wed, 08 Jan 2020 16:45:33 +0000
Bug 1606685 - Support empty tiles within compositor surfaces. r=sotaro This adds support for holes within virtual surfaces. On platforms that don't use virtual surfaces, this just works by destroying the tile that is empty so it never gets composited. Differential Revision: https://phabricator.services.mozilla.com/D59059
1d212c2ddb76f5d54fd884e8e08001fc8475e13c: Bug 1607352 - Support DirectComposition virtual surface API. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Tue, 07 Jan 2020 20:42:58 +0000 - rev 509215
Push 36993 by dluca@mozilla.com at Wed, 08 Jan 2020 09:41:58 +0000
Bug 1607352 - Support DirectComposition virtual surface API. r=sotaro Adds an #ifdef to the DCLayerTree implementation that allows selecting whether to use the virtual surface API (enabled by default) or the regular DC surface API. For now, this is a compile-time switch. As a follow up to this, we will support both options at runtime (for example, using the regular surface API for surfaces that have holes or translucency). Differential Revision: https://phabricator.services.mozilla.com/D58870
f443172cae02e3835bd4f3ca38cb4331271cc86a: Bug 1604684 - Make opacity a compositor surface property rather than a tile property. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Mon, 06 Jan 2020 20:11:21 +0000 - rev 508977
Push 36987 by nerli@mozilla.com at Tue, 07 Jan 2020 05:13:50 +0000
Bug 1604684 - Make opacity a compositor surface property rather than a tile property. r=sotaro This will allow use of the DirectComposition virtual surface API. If it turns out that some pages recreate surfaces a lot due to opacity changing, we can add some extra logic to avoid recreating surfaces as often, and making use of per-tile opacity in some cases. Differential Revision: https://phabricator.services.mozilla.com/D57592
5bef477e99caae479472e79c5fd4cc9f6908826c: Bug 1604412 - Duplicate WinCompositorWidget logic into subclasses r=sotaro
Chris Martin <cmartin@mozilla.com> - Mon, 06 Jan 2020 07:39:42 +0000 - rev 508945
Push 36986 by nerli@mozilla.com at Mon, 06 Jan 2020 21:54:03 +0000
Bug 1604412 - Duplicate WinCompositorWidget logic into subclasses r=sotaro This looks like a large change, but it's really just moving stuff around. It takes the logic in WinCompositorWidget and duplicates it into its only 2 subclasses: InProcessWinCompositorWidget and CompositorWidgetParent. This is because CompositorWidgetParent is about to change *a lot*, but InProcessWinCompositorWidget will basically stay the same. This is an easy way to verify that I don't accidently break InProcessWinCompositorWidget. Differential Revision: https://phabricator.services.mozilla.com/D57428
2dd771769da78bd16ddc7d4928030e5ae8a9ac90: Bug 1604827 - Workaround for stale tile content in native compositor mode. r=sotaro
dev <dev@devs-MacBook-Pro.local> - Thu, 19 Dec 2019 01:38:34 +0000 - rev 507684
Push 36931 by opoprus@mozilla.com at Thu, 19 Dec 2019 09:50:06 +0000
Bug 1604827 - Workaround for stale tile content in native compositor mode. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D57711
c81cf0c409bcaea6a6e6299cb2f421e4528e023b: Bug 1604383 - Refactor the Compositor trait to allow support for DC virtual surface API. r=mstange,sotaro
Glenn Watson <git@intuitionlibrary.com> - Tue, 17 Dec 2019 21:44:03 +0000 - rev 507464
Push 36928 by opoprus@mozilla.com at Wed, 18 Dec 2019 09:16:14 +0000
Bug 1604383 - Refactor the Compositor trait to allow support for DC virtual surface API. r=mstange,sotaro Differential Revision: https://phabricator.services.mozilla.com/D57415
b85d5793f58d9d0b45bbbfe67b89708701e1404a: Bug 1604088 - Switch OS compositor off by default on Windows. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Mon, 16 Dec 2019 03:39:27 +0000 - rev 507040
Push 36921 by nerli@mozilla.com at Mon, 16 Dec 2019 09:50:52 +0000
Bug 1604088 - Switch OS compositor off by default on Windows. r=sotaro This switches the OS compositor integration for WR on Windows off by default. There are a couple of issues (primarily performance related) that we need to fix up before making it the default for a release. Differential Revision: https://phabricator.services.mozilla.com/D57267
73b2a65e1bfb1b8c561b79e9ece2dbde069159b6: Bug 1603207 - Only enable native compositor if picture caching enabled. r=sotaro
Glenn Watson <git@intuitionlibrary.com> - Thu, 12 Dec 2019 00:08:38 +0000 - rev 506593
Push 36908 by malexandru@mozilla.com at Thu, 12 Dec 2019 09:53:26 +0000
Bug 1603207 - Only enable native compositor if picture caching enabled. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D56817