We already avoid scene rebuilding for animated image frame updates, but
we can easily apply this to still images. If the decoding is happening
slowly and in chunks for some reason (really large image, slow network),
then we may save some work.
We lose some sugar but gain some safety. This seems like the right
trade. If people want sugar they should use Rust.
Differential Revision: https://phabricator.services.mozilla.com/D16918
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
It looks like we can do initialization and destruction from the UI
thread before the bits that run on the Compositor thread have run. Avoid
this by synchronously waiting on the Compositor.
Differential Revision: https://phabricator.services.mozilla.com/D16596
--HG--
extra : moz-landing-system : lando
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
The old vector recycler had a few problems:
1. shrinking to fit would be inevitably followed by re-allocation, since it's unlikely that the consequent sizes are below the immediately followed frames
2. shrinking before clearing means that the existing contents are copied over, which is a waste
The new code has more complicated logic for recycling, aimed at reducing heap allocations. It's also collecting the statistics.
Differential Revision: https://phabricator.services.mozilla.com/D16496
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
The tests for Bug 1133905 all compare the visibility of scrollbars with
differently-sized css viewports. This patch has some affect on the
viewport sizing that I don't understand, and it causes some of the tests
to start passing and some to start failing.
The test for Bug 1242172 has elements sized to height 100% and checking
for the presence or absence of scrollbars. In this case the patch appears
to increase the css viewport height and decrease the width -- again for
reasons I don't understand -- and this affects the scrollbar sizes.
Differential Revision: https://phabricator.services.mozilla.com/D16078
--HG--
extra : moz-landing-system : lando
This does two things:
* Ensures that the T gets dropped when the item is removal, which is
important for the TextRunKey case where it holds heap memory.
* Eliminates the epoch handling while still ensuring that we panic on
stale lookups.
We also remove the Item usage for local_data, but don't bother with the
Option in that case.
Differential Revision: https://phabricator.services.mozilla.com/D16629
Currently there are two conditions where CONTENT_FRAME_TIME_REASON can
be NoVsync. Since, were getting an appreciable amount of these with
WebRender it makes sense to split out the telemetry so that we can
confirm which scenario we're hitting.
Differential Revision: https://phabricator.services.mozilla.com/D16611
--HG--
extra : moz-landing-system : lando
