Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
This update brings in several bugfixes and compatibility with newer
libstdc++ versions.
Differential Revision: https://phabricator.services.mozilla.com/D45860
--HG--
extra : moz-landing-system : lando
This also changes CompositorBridgeChild to create the CanvasChild lazily.
Depends on D44154
Differential Revision: https://phabricator.services.mozilla.com/D44873
--HG--
extra : moz-landing-system : lando
If VR process haven't launched yet, we couldn't get available VR displays and its states, so we need to make enumationCompleted to be false, and ask it do the enumeration again.
Differential Revision: https://phabricator.services.mozilla.com/D46238
--HG--
extra : moz-landing-system : lando
Preparation work for adding DirectComposition support. It does not add a new functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46429
--HG--
extra : moz-landing-system : lando
We only use the png codec so let's save some link time by not including
the other codecs.
Differential Revision: https://phabricator.services.mozilla.com/D46317
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
IDCompositionDevice::Commit needs to be called when there is an update to DirectComposition. RenderCompositorANGLE updates DirectComposition only during initialization. Then it is not necessary to call the function in EndFrame().
Differential Revision: https://phabricator.services.mozilla.com/D46249
--HG--
extra : moz-landing-system : lando
This fixes a case where the is_same_content field was no longer
being reset to true before dependency calculation could occur.
In some cases, this could result in a tile being updated, but
the dirty rect being empty, which meant all primitives in that
tile would fail the visibility culling test.
Differential Revision: https://phabricator.services.mozilla.com/D46247
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
This provides the internal device-space dirty rects calculated
during picture cache updates to the external render() method.
This allows clients to provide these to OS partial present APIs,
to reduce power usage and improve performance.
In this initial implementation, if a scroll or scale of the main
picture cache has occurred, the dirty rect will be the entire
screen. This should ensure correctness. In future, we can handle
this case by supplying the picture cache transforms to the OS
compositor integration.
However, the dirty rects will be valid for any non-scroll cases,
such as animations or video playback. This should result in some
significant power savings and performance improvements for these
use cases.
Differential Revision: https://phabricator.services.mozilla.com/D46082
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
This works by keeping track of the previous visible rect and
computing a preserved rect by intersecting with the new visible
rect.
We force the dirty rect to be inside this preserved area.
Differential Revision: https://phabricator.services.mozilla.com/D45284
--HG--
extra : moz-landing-system : lando
Previously after RecvResumeAndResize() we would set a flag on the root
WebRenderBridgeParent, which in turn sets a flag on the next display list it
receives that it should be treated as a first paint. Then when that display list
is finally composited, we call UiCompositorControllerParent::NotifyFirstPaint(),
which in turn tells GeckoView to uncover the widget.
After switching tabs in GeckoView browsers, however, the root
WebRenderBridgeParent does not always receive a new display list, so the widget
would not be uncovered. Instead of waiting for the next received display list to
be composited, we simply want to uncover the widget on the next composite. To
achieve this we instead set the forced-first-paint flag on the root
CompositorBridgeParent then we call NotifyFirstPaint() during
CompositorBridgeParent::NotifyPipelineRendered().
Differential Revision: https://phabricator.services.mozilla.com/D46157
--HG--
extra : moz-landing-system : lando
We compute the preserved bounds for each item and see if it's
contained in the invalid area. The gecko side will do the same
computation.
Appologies for duplicating euclid with Box2d type. We can deal with
that in a followup.
The asserts are disabled for now. I tried reenabling them and they
triggered. I haven't had a chance to figure out if they are still
valid.
Differential Revision: https://phabricator.services.mozilla.com/D45283
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--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
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
