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