Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
So we don't need to create motion path data if there is no offset-path style
and no animations of offset-path.
Differential Revision: https://phabricator.services.mozilla.com/D57907
--HG--
extra : moz-landing-system : lando
The benefits are:
1. For the rest `layers::Animation`s, their `TransformData` are `Nothing()`,
so we can avoid any posisible copy.
2. In the compositor, we move `TransformData` out of the array, and use
`UniquePtr` to avoid including AnimationHelper.h into AnimationInfo.h,
which causes some compilation errors because LayersMessages.h is not
visible in AnimationInfo.h.
Differential Revision: https://phabricator.services.mozilla.com/D57751
--HG--
extra : moz-landing-system : lando
This makes it more similar to how SwapBuffers was used.
This patch also makes us call glFlush directly when using native layers, rather than going through the misleadingly-named GLContext::SwapBuffers method.
Differential Revision: https://phabricator.services.mozilla.com/D57062
--HG--
extra : moz-landing-system : lando
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
The only use of this was inside Android's nsWindow::PreRender.
That method was removed in changeset 81de9d1439b0e352729142f6aa2914674073da03 (bug 1335895).
Differential Revision: https://phabricator.services.mozilla.com/D53771
--HG--
extra : moz-landing-system : lando
The gap is caused by the difference between 'fixed margin' on the compositor
based on the state where the dynamic toolbar is completely visible and
position:fixed elements positioned by the time where is partially visible or
completely hidden. That's because the 'fixed margin' is computed based on the
bottom of the ICB whereas position:fixed elements are slightly shifted from the
ICB edge during the toolbar transition.
Differential Revision: https://phabricator.services.mozilla.com/D52337
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
SurfaceDescriptorGPUVideo, which currently only represents RemoteDecoder video, switches from being a struct to a union that holds a SurfaceDescriptorRemoteDecoder struct. SurfaceDescriptorRemoteDecoder is a new name for the old SurfceDescriptorGPUVideo. This is done so that we can later add SurfaceDescriptorPlugin as another type of SurfaceDescriptorGPUVideo.
Differential Revision: https://phabricator.services.mozilla.com/D52400
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.
I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D51466
--HG--
extra : moz-landing-system : lando
We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50013
--HG--
extra : moz-landing-system : lando
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
--HG--
extra : moz-landing-system : lando
This change makes opaqueness a boolean per layer again. The opaque region is
currently only used by the temporary WebRender code; the future WebRender code
won't use it. Removing this support simplifies the code and makes it easier to
implement clipping.
Differential Revision: https://phabricator.services.mozilla.com/D50722
--HG--
extra : moz-landing-system : lando
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
It's still only used on Android, but keeping it and all code that interacts
with it inside an #ifdef is too much trouble for a tiny amount of space
saving.
Differential Revision: https://phabricator.services.mozilla.com/D48369
--HG--
extra : moz-landing-system : lando
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
This layer structure can still occur in cases where we place the RCD-RSF
scroll metadata on the root layer as a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D47655
--HG--
extra : moz-landing-system : lando
With container scrolling, layers that are fixed wrt. the RCD-RSF are no
longer descendants of layers with RCD-RSF metadata. This allows us to remove
some code that handles this case in AsyncCompositionManager.
In particular, when ApplyAsyncContentTransformToTree() calls
AlignFixedAndStickyLayers():
- If we are currently processing a layer with RCD-RSF metadata,
AlignFixedAndStickyLayers() will not do anything (because there will be
no descendants fixed wrt. the RCD-RSF), so it doesn't matter what
transform we pass to AlignFixedAndStickyLayers().
- If we are processing a different layer, then Metrics().IsRootContent()
will be false, so GetCurrentAsyncTransformForFixedAdjustment()
simplifies to just GetCurrentAsyncTransform().
As a result, GetCurrentAsyncTransformForFixedAdjustment() (and its helper
GetCurrentAsyncViewportTransform()) can be removed, and its use replaced
with GetCurrentAsyncTransform().
Differential Revision: https://phabricator.services.mozilla.com/D45595
--HG--
extra : moz-landing-system : lando
With containerless scrolling, scrollbar layers and their target scrolled layers
will be in sibling subtrees.
Depends on D45596
Differential Revision: https://phabricator.services.mozilla.com/D45918
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
