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
This fixes the regression in reftests/text/color-opacity-rtl-[12].html.
This also reverts an earlier erroneous change to WPT content-counter-004.xht
that was done in https://hg.mozilla.org/mozilla-central/rev/c969a93b0ca7
to silence an unexpected-pass that accidentally arose because of matching
failures in test/ref when we switched to GetFTGlyphExtents in
https://hg.mozilla.org/mozilla-central/rev/003f5a79c6a7. Now that the
actual scaling issue is fixed, the behavior is again consistent with Cairo
metrics causing the failure to reappear like before with Cairo metrics.
Differential Revision: https://phabricator.services.mozilla.com/D45956
--HG--
extra : moz-landing-system : lando
Previously, primitive lists were stored as:
PicturePrimitive
PrimitiveList
[PrimitiveInstance]
[PrimitiveCluster]
[PictureIndices]
Each primitive instance contained a spatial node index and an
index into the primitive cluster it belongs to.
Now, the instances in a primitive list are stored as:
PicturePrimitive
PrimitiveList
[PrimitiveCluster]
[PrimitiveInstance]
This provides a number of advantages:
* Size of the PrimitiveInstance struct is smaller.
* No need to maintain a separate PictureIndices list.
* Easy and fast to skip the array, finding pictures or scroll root changes.
* Much faster to split and reorder PrimitiveList structures.
This patch is refactoring only, it doesn't contain any functional
changes. As we enable multiple picture caching slices, we need to
be able to split and reorder PrimitiveLists. Storing the primitive
instances in this way makes that process much more efficient than
it currently is.
Differential Revision: https://phabricator.services.mozilla.com/D45636
--HG--
extra : moz-landing-system : lando
The snapping during scene building is unable to take into account scroll
offsets. Since we have already snapped the primitive rects in the raster
space, we know that this can only result in a translation rather than a
size change, and thus is safe to do during frame building.
When we update the transform tree, we now snap the scroll offset in
device space to ensure that scroll offsets should primarily be integer
offsets and not have snapping implications.
The local rect of a picture is calculated during the first picture
traversel. It is composed of already snapped primitives, however the
picture itself may inflate itself, and thus is now snapped again as part
of inflation.
Differential Revision: https://phabricator.services.mozilla.com/D45060
--HG--
extra : moz-landing-system : lando
Now that rounding has been removed from Gecko, we need to start snapping
properly in WebRender. Snapping can change the size of a primitive, and
thus it is problematic to do any later than scene building due to the
GPU caching and sharing of data between clips and such that only differ
in their positioning.
This patch produces a snapping transform which allows any primitive to
snap using information known during scene building. This excludes
animated tranforms which are assumed to be the identity. This allows for
primitives that are marked as will-change: transform but given no
initial transform to render the same as primitives that are not. This
also excludes scroll positioning because that is not known until frame
building. A follow up patch will deal with that.
Differential Revision: https://phabricator.services.mozilla.com/D45059
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
This will be rewritten in a later patch in the series. The shaders will
be provided the correct information and will no longer need to concern
themselves with snapping.
Differential Revision: https://phabricator.services.mozilla.com/D45057
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
The snapping during scene building is unable to take into account scroll
offsets. Since we have already snapped the primitive rects in the raster
space, we know that this can only result in a translation rather than a
size change, and thus is safe to do during frame building.
When we update the transform tree, we now snap the scroll offset in
device space to ensure that scroll offsets should primarily be integer
offsets and not have snapping implications.
The local rect of a picture is calculated during the first picture
traversel. It is composed of already snapped primitives, however the
picture itself may inflate itself, and thus is now snapped again as part
of inflation.
Differential Revision: https://phabricator.services.mozilla.com/D45060
--HG--
extra : moz-landing-system : lando
Now that rounding has been removed from Gecko, we need to start snapping
properly in WebRender. Snapping can change the size of a primitive, and
thus it is problematic to do any later than scene building due to the
GPU caching and sharing of data between clips and such that only differ
in their positioning.
This patch produces a snapping transform which allows any primitive to
snap using information known during scene building. This excludes
animated tranforms which are assumed to be the identity. This allows for
primitives that are marked as will-change: transform but given no
initial transform to render the same as primitives that are not. This
also excludes scroll positioning because that is not known until frame
building. A follow up patch will deal with that.
Differential Revision: https://phabricator.services.mozilla.com/D45059
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
This will be rewritten in a later patch in the series. The shaders will
be provided the correct information and will no longer need to concern
themselves with snapping.
Differential Revision: https://phabricator.services.mozilla.com/D45057
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
The snapping during scene building is unable to take into account scroll
offsets. Since we have already snapped the primitive rects in the raster
space, we know that this can only result in a translation rather than a
size change, and thus is safe to do during frame building.
When we update the transform tree, we now snap the scroll offset in
device space to ensure that scroll offsets should primarily be integer
offsets and not have snapping implications.
The local rect of a picture is calculated during the first picture
traversel. It is composed of already snapped primitives, however the
picture itself may inflate itself, and thus is now snapped again as part
of inflation.
Differential Revision: https://phabricator.services.mozilla.com/D45060
--HG--
extra : moz-landing-system : lando
Now that rounding has been removed from Gecko, we need to start snapping
properly in WebRender. Snapping can change the size of a primitive, and
thus it is problematic to do any later than scene building due to the
GPU caching and sharing of data between clips and such that only differ
in their positioning.
This patch produces a snapping transform which allows any primitive to
snap using information known during scene building. This excludes
animated tranforms which are assumed to be the identity. This allows for
primitives that are marked as will-change: transform but given no
initial transform to render the same as primitives that are not. This
also excludes scroll positioning because that is not known until frame
building. A follow up patch will deal with that.
Differential Revision: https://phabricator.services.mozilla.com/D45059
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
This will be rewritten in a later patch in the series. The shaders will
be provided the correct information and will no longer need to concern
themselves with snapping.
Differential Revision: https://phabricator.services.mozilla.com/D45057
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
Other patches in this series change blob-related coordinate systems which
means rawtests have to be adapted since the previous test parameters will
now give different results.
In addition, the new model for specifying blobs mtaches the visible area
to the layout rectangle of the primitive, which means there is no more
decorrelation between the item and the portion of it that needs rendering,
so one of the test is adapted accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D41387
--HG--
extra : moz-landing-system : lando
This also removes a dependency on rand 0.4 getting it closer to being
able to remove that.
Differential Revision: https://phabricator.services.mozilla.com/D45710
--HG--
extra : moz-landing-system : lando
The snapping during scene building is unable to take into account scroll
offsets. Since we have already snapped the primitive rects in the raster
space, we know that this can only result in a translation rather than a
size change, and thus is safe to do during frame building.
When we update the transform tree, we now snap the scroll offset in
device space to ensure that scroll offsets should primarily be integer
offsets and not have snapping implications.
The local rect of a picture is calculated during the first picture
traversel. It is composed of already snapped primitives, however the
picture itself may inflate itself, and thus is now snapped again as part
of inflation.
Differential Revision: https://phabricator.services.mozilla.com/D45060
--HG--
extra : moz-landing-system : lando
Now that rounding has been removed from Gecko, we need to start snapping
properly in WebRender. Snapping can change the size of a primitive, and
thus it is problematic to do any later than scene building due to the
GPU caching and sharing of data between clips and such that only differ
in their positioning.
This patch produces a snapping transform which allows any primitive to
snap using information known during scene building. This excludes
animated tranforms which are assumed to be the identity. This allows for
primitives that are marked as will-change: transform but given no
initial transform to render the same as primitives that are not. This
also excludes scroll positioning because that is not known until frame
building. A follow up patch will deal with that.
Differential Revision: https://phabricator.services.mozilla.com/D45059
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
This will be rewritten in a later patch in the series. The shaders will
be provided the correct information and will no longer need to concern
themselves with snapping.
Differential Revision: https://phabricator.services.mozilla.com/D45057
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
`register` isn't allowed in C++17, but cairo is too old to care.
Instead of turning off the warning, just use the `__builtin_popcount`
path for clang. This path also applies to clang-cl.
Differential Revision: https://phabricator.services.mozilla.com/D44047
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
The rect will be used for calculating the result of the composition of the
remote display item on the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D44419
--HG--
extra : moz-landing-system : lando
This patch adds a simple quadtree structure to each picture cache
tile. This tree is used to track dirty regions of each tile. By
using a tree that can split / merge nodes, the CPU overhead of
tracking dirty areas is minimized, by only splitting nodes where
content is regularly changing.
For now, this patch makes use of the dirty rects to set a single
scissor rect when rendering picture cache tiles. This results in
a significant performance improvement (due to fewer pixels being
drawn) on many pages. In future, the dirty rects will also be
exposed at the API level, allowing clients to leverage partial
present APIs for power saving purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45287
--HG--
extra : moz-landing-system : lando
This also makes sure that we invalidate for any visible rect bounds changes.
This makes more sense even if it's more conservative.
Differential Revision: https://phabricator.services.mozilla.com/D45325
--HG--
extra : moz-landing-system : lando
This also makes sure the SourceSurfaceCanvasRecording clean-up is done on the
main thread where required.
Differential Revision: https://phabricator.services.mozilla.com/D43077
--HG--
extra : moz-landing-system : lando
Null checks have been added for the recorder in CanvasChild to prevent crashes
during shutdown.
This also removes mCanSend in CanvasParent and uses CanSend() instead.
Differential Revision: https://phabricator.services.mozilla.com/D43076
--HG--
extra : moz-landing-system : lando
Previously we were only doing this if content wasn't prevent-defaulting the
events targeting the new APZC.
Differential Revision: https://phabricator.services.mozilla.com/D44712
--HG--
extra : moz-landing-system : lando
This fixes a bug that was introduced three years ago in bug 1268854.
What happened was that the final pass over the polygon assumed that the current
polygon was living in plane[0]. But due to the double buffering, the "current"
polygon alternates between plane[0] and plane[1]. And bug 1268854 had introduced
an early exit so that we could hit the final pass at a time where the current,
now empty, polygon was in plane[1]. So we would incorrectly treat all 32 points
in plane[0] as part of the final polygon.
This bug was responsible for intermittently unreasonable numbers in CompositorOGL's fill
rate / overdraw overlay, and, since changeset cc84a0e9d5ddde198422f4f11ab6bf85f631d5f0,
also caused CompositorOGL to execute unnecessary draw calls.
Differential Revision: https://phabricator.services.mozilla.com/D44312
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
This isn't needed any more and conflicts with the changes happening in bug 1579404
Differential Revision: https://phabricator.services.mozilla.com/D44998
--HG--
extra : moz-landing-system : lando
No need to check twice and this will make it cleaner when we change the condition.
Differential Revision: https://phabricator.services.mozilla.com/D44994
--HG--
extra : moz-landing-system : lando
Previously, primitive sub-dependencies (such as transforms, opacity
bindings etc) were invalidated by comparing the dependency array
only. This means that it's not possible to correlate an area of
a tile that is affected by those sub-dependencies.
Now, comparisons on sub-dependencies are handled as part of the
dependency check for each primitive. This means we have the
affected rectangle of the tile available, which will allow
dirty regions within a tile to be built correctly.
This patch is only preparation work - the actual dirty rect
calculation will be done as a follow up patch.
Differential Revision: https://phabricator.services.mozilla.com/D44771
--HG--
extra : moz-landing-system : lando
This change introduces the HTML-based UI for the 2D Content window in Firefox
Reality for Desktop, accessed via the --fxr command line parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42546
--HG--
extra : moz-landing-system : lando
Falls back to 'false' in non-nightly builds instead of using the gfx.webrender.start-debug-server pref, which is only available in nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D44743
--HG--
extra : moz-landing-system : lando
Previously, picture caching code would use the viewport of the
scroll root to find a clipping rect for picture cache tiles. This
viewport rect was also used to eliminate fixed position clip rects
on primitives that would otherwise cause unwanted invalidations
due to them moving relative to the scroll root when scrolls occur.
Now, the picture caching code uses a similar technique to Gecko
to find shared clips on primitives in a picture cache. These clips
are filtered out from being applied on a per-primitive basis, and
instead applied once during compositing the tiles into the parent
picture.
This is a potential performance improvement, since less per-item
work is required when building clip chains. More importantly, it
means the picture caching code correctly handles cases where the
scroll root contains fixed position elements (or other scroll
roots). This is a requirement before we can enable picture caching
on multiple slices.
Differential Revision: https://phabricator.services.mozilla.com/D44618
--HG--
extra : moz-landing-system : lando
This change introduces plumbing for communicating with the GPU process through
VRShMem while bootstrapping Firefox for creating a window with Firefox Reality.
Test impact shows a fabricated value returned for the texture handle in VRShMem.
Differential Revision: https://phabricator.services.mozilla.com/D41383
--HG--
extra : moz-landing-system : lando
This change introduces the HTML-based UI for the 2D Content window in Firefox
Reality for Desktop, accessed via the --fxr command line parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42546
--HG--
extra : moz-landing-system : lando
Gather stats for most calls to `profiler_add_marker()`, including the time to
allocate payloads if any.
Differential Revision: https://phabricator.services.mozilla.com/D43420
--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
Previously, clip nodes interned the local clip information, but
stored the spatial node and the local position as part of the
instance.
This was required since the local position of clips would change
when a new display was sent after scrolling. However, since we
now handle this via external scroll offsets, the local position
is stable, and we can intern both the position and spatial node.
This greatly simplifies some in-progress work for picture caching,
where we want to be able to quickly identify clip chain nodes that
are shared between elements of a display list. With this change,
comparing the item uid of the interned clip node is enough to
guarantee equality of the shared clips.
Differential Revision: https://phabricator.services.mozilla.com/D44436
--HG--
extra : moz-landing-system : lando
I had accidentally flipped things around so that the framebuffers were only
deleted when a registry was set.
Differential Revision: https://phabricator.services.mozilla.com/D44411
--HG--
extra : moz-landing-system : lando
This makes the fill rate numbers which are displayed in the FPS overlay a lot more reasonable.
It also requires the TransformAndClipBounds fix from bug 1578045 for correct numbers.
Depends on D44337
Differential Revision: https://phabricator.services.mozilla.com/D44338
--HG--
extra : moz-landing-system : lando
This creates and updates layers that draw the same things as RenderDebugOverlay().
The code is duplicated so that the overlay can be independent of the compositing
layer content drawing. All layers need to be drawn first, and the GPU stats from
that layer are shown in mGPUStatsLayer.
Depends on D44336
Differential Revision: https://phabricator.services.mozilla.com/D44337
--HG--
extra : moz-landing-system : lando
This essentially backs out the two patches from bug 1565668 that added this
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D44330
--HG--
extra : moz-landing-system : lando
CompositingRenderTargetOGL objects are no longer reused between frames. They are
recreated each frame around a reused framebuffer. This lets us remove the
SetOrigin method again, because we specify the right render target origin on
creation.
Depends on D44328
Differential Revision: https://phabricator.services.mozilla.com/D44329
--HG--
extra : moz-landing-system : lando
This returns the raw framebuffer GLuint and lets the caller bind it.
Initially I wanted to return a RefPtr<MozFramebuffer>, but then I discovered
that MozFramebuffer is not a refcounted class and prefers UniquePtrs.
Depends on D44324
Differential Revision: https://phabricator.services.mozilla.com/D44325
--HG--
extra : moz-landing-system : lando
This uses MacIOSurface internally. NextSurfaceAsDrawTarget locks the MacIOSurface,
and NotifySurfaceReady unlocks it if necessary.
Depends on D44321
Differential Revision: https://phabricator.services.mozilla.com/D44322
--HG--
extra : moz-landing-system : lando
The comments above these methods refer to NextSurface* methods which will be
added in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D44321
--HG--
extra : moz-landing-system : lando
The tile size is configurable with the prefs layers.compositing-tiles.width/height.
On macOS, whenever a CALayer is touched, the window server will recomposite the
entire layer to the screen. There is no API to mark parts of a layer as damaged.
So if we want the window server to only redraw a small part of the screen, we
need to only touch small layers. This patch achieves that using tiles; whenever
the compositor needs to redraw an area, all tiles that overlap this area will
be drawn to their layers and the window server will recomposite those layers.
On Intel GPUs, compositing in tiles should also help reduce GPU times if there
are multiple layers of overdraw: The overdraw will have better cache locality.
However, the magnitude of this effect is not known and requires further research.
Differential Revision: https://phabricator.services.mozilla.com/D43881
--HG--
extra : moz-landing-system : lando
This means that when something changes in an opaque layer, the window server
only needs to copy the opaque layer to the screen and can avoid recomputing any
window backgrounds for transparent parts of the window. This can save power,
especially when transparent parts of the window use the macOS vibrancy effect,
which requires the window server to compute a blur and to composite windows
behind our window.
Differential Revision: https://phabricator.services.mozilla.com/D43880
--HG--
extra : moz-landing-system : lando
This change breaks the draw-fps overlay when using native layers. I'll try to
fix that in a new bug soon.
The do { } while(0) loop looks a bit odd, but it'll get replaced with a proper
loop in bug 1574586.
Differential Revision: https://phabricator.services.mozilla.com/D43879
--HG--
extra : moz-landing-system : lando
This makes profiler screenshots and frame recording work again, when native
layers are used. The copying is a bit unfortunate. Maybe we can combine this
copy with the first downscaling step in the future. Or for frame recording,
which doesn't use downscaling, we could readback the layers individually and
reassemble them in CPU memory. But both of those solutions are more complex
than this.
Differential Revision: https://phabricator.services.mozilla.com/D43877
--HG--
extra : moz-landing-system : lando
This is so that we can invalidate all layers when screenshot profiling has
started, and not just the first layer.
Differential Revision: https://phabricator.services.mozilla.com/D43874
--HG--
extra : moz-landing-system : lando
This removes any *TargetContext methods from the Compositor interface and moves
mTarget tracking into the compositor implementations.
Differential Revision: https://phabricator.services.mozilla.com/D43872
--HG--
extra : moz-landing-system : lando
In the end we want to have BeginFrameForWindow, BeginFrameForTarget, and
BeginFrameForNativeLayers, the latter with multiple Begin/EndRenderingToNativeLayer
pairs nested inside.
This is the first step.
CompositorOGL and CompositorD3D11 keep their internal BeginFrame method but make
it private.
Differential Revision: https://phabricator.services.mozilla.com/D43871
--HG--
extra : moz-landing-system : lando
The call to TransformAndClipBounds already clips destRect to renderBounds.
However, if the resulting rect was empty, the Inflate call would make it
non-empty again. And now the decision whether we would cull would depend on the
rect's position: Sometimes TransformAndClipBounds would place the empty rect at
a position along an edge of renderBounds, and then the inflated-from-nothingness
2x2 rect would overlap renderBounds and we wouldn't cull.
Differential Revision: https://phabricator.services.mozilla.com/D43870
--HG--
extra : moz-landing-system : lando
aClipRect is relative to
closestAncestorContainerLayerWithIntermediateSurface->GetVisibleRegion().GetBounds().TopLeft()
or (0, 0) if there is no ancestor with an intermediate surface.
It gets computed by Layer::CalculateScissorRect.
So if there is an intermediate surface, that origin matches the render target
origin. But if there is no intermediate surface, it does not always match: the
root render target's origin is not necessarily (0, 0).
In the past, BasicCompositor dealt with this by using the transform on the root
render target's mDrawTarget, which gets set in CreateRenderTargetAndClear
(renamed to CreateRootRenderTarget in this patch). Render targets created in the
regular CreateRenderTarget did not have a transform.
This allowed DrawGeometry to only conditionally apply an offset to aClipRect;
the offset was applied by calling PushClipRect before resetting the transform.
Now all render targets have a translation by -offset on their DrawTarget, not
just the root render target.
I went with an explicit "clip space origin" field on the render target.
Other alternatives would have been:
- Having a bool IsRootRenderTarget() and using that to conditionally offset
aClipRect by the render target origin or not.
- Changing Layer::CalculateScissorRect so that the clip space origin is always
(0, 0). I actually tried this first but ran into trouble with the MLGPU code.
We can do it later.
Differential Revision: https://phabricator.services.mozilla.com/D43866
--HG--
extra : moz-landing-system : lando
This also fixes DrawTargetSkia::CanCreateSimilarDrawTarget because currently
if only one of the height or width is negative then it doesn't get caught.
Differential Revision: https://phabricator.services.mozilla.com/D43075
--HG--
extra : moz-landing-system : lando
The old code was making an autoRestoreTransform around dest and then quickly
overwriting dest with something new. I prefer creating the autoRestoreTransform
for buffer, which doesn't change over the course of this function.
Differential Revision: https://phabricator.services.mozilla.com/D43384
--HG--
extra : moz-landing-system : lando
This removes one user of mDrawTarget.
This change only makes a difference when we have a backbuffer; now we will create
DrawTargets that are similar to the back buffer instead of the front buffer.
Differential Revision: https://phabricator.services.mozilla.com/D43381
--HG--
extra : moz-landing-system : lando
This makes it clear that only one of the possible call paths of
CreateRenderTargetForWindow can use a back buffer.
It causes some unfortunate duplication of the clear region computation.
Differential Revision: https://phabricator.services.mozilla.com/D43380
--HG--
extra : moz-landing-system : lando
This eliminates a boolean parameter whose meaning is not immediately obvious at the call site.
Depends on D43378
Differential Revision: https://phabricator.services.mozilla.com/D43379
--HG--
extra : moz-landing-system : lando
None of the three main if branches in TryToEndRemoteDrawing were entered in that case:
- if (!aForceToEnd && !mTarget && NeedsToDeferEndRemoteDrawing()) wasn't entered because
mTarget was non-null.
- if (mRenderTarget->mDrawTarget != mDrawTarget) wasn't entered because mTarget
drawing doesn't use a back buffer.
- if (aForceToEnd || !mTarget) wasn't entered because aForceToEnd was false and
mTarget was non-null.
Depends on D43377
Differential Revision: https://phabricator.services.mozilla.com/D43378
--HG--
extra : moz-landing-system : lando
It turns out there's not much benefit to creating the DrawTarget at the beginning of the frame.
It's only needed between NormalDrawingDone() and EndFrame().
Depends on D43376
Differential Revision: https://phabricator.services.mozilla.com/D43377
--HG--
extra : moz-landing-system : lando
Whenever *aRenderBoundsOut was non-empty and aClipRectOut was non-null,
*aClipRectOut was set to the same value as *aRenderBoundsOut.
Depends on D43368
Differential Revision: https://phabricator.services.mozilla.com/D43369
--HG--
extra : moz-landing-system : lando
There are three circumstances that make these transformations equivalent:
- aClipRectIn and aClipRectOut are never both non-null.
- The value of *aClipRectOut is ignored if *aRenderBoundsOut is empty.
- aRenderBounds.TopLeft() is always (0, 0) because the ClientLayerManager
calls targetBounds.MoveTo(0, 0) on the rect that eventually becomes
aRenderBounds.
(targetBounds -> Transaction::mTargetBounds -> TargetConfig::naturalBounds()
-> LayerManagerComposite::mRenderBounds)
Depends on D43367
Differential Revision: https://phabricator.services.mozilla.com/D43368
--HG--
extra : moz-landing-system : lando
This is a remnant from the previous implementation of masking. That
implementation was replaced in bug 1447880.
Differential Revision: https://phabricator.services.mozilla.com/D43763
--HG--
extra : moz-landing-system : lando
On platforms that don't use native layers for rendering, we usually want reftests
to see exactly what's going to end up in the window. It's conceivable that
rendering into offscreen framebuffers might miss bugs on those platforms (though
I'm not sure if we've seen any evidence of this).
But when we're rendering to native layers, we have non-default framebuffers either
way, so we might as well create our own framebuffer rather than asking a native
layer for one. We're not interested in getting this rendering to the screen, so
it's better to leave the native layer out of this.
Differential Revision: https://phabricator.services.mozilla.com/D42406
--HG--
extra : moz-landing-system : lando
This makes CompositorOGL always render into offscreen render targets.
CompositorOGL no longer expects the GLContext to have a default framebuffer.
This duplicates a bunch of code from GLContextCGL, but that code can be removed
from GLContextCGL once WebRender no longer needs it.
This also makes it so that we don't recreate render targets on every frame;
instead, we create one render target for every IOSurface in the native layer's
"swap chain" and cycle through those render targets. We only throw away the
render targets when the window is resized or closed.
Differential Revision: https://phabricator.services.mozilla.com/D42405
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
It's a really minor perf improvement, but also a cleanup IMO.
Also be a bit more const-correct while at it.
Differential Revision: https://phabricator.services.mozilla.com/D42985
--HG--
extra : moz-landing-system : lando
