We currenly only support the dynamic toolbar at bottom, so we apply the
`fixed margin offset` only if the sticky element is stuck at the bottom
of the root scroll container.
Differential Revision: https://phabricator.services.mozilla.com/D60066
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
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
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
Kartikaya Gupta
Sylvestre Ledru
sotaro
Simon Giesecke
Markus Stange
shindli
Hiroyuki Ikezoe
Botond Ballo
Emilio Cobos Álvarez
Dorel Luca
Boris Chiou
Sean Feng
David Parks
James Hooks
Cosmin Sabou
Barret Rennie
Daniel Varga
Dan Glastonbury
Razvan Maries
Lee Salzman
alwu