ProfilerScreenshots encodes these surfaces to JPG data URLs, and submits them
as profiler markers. The encoding is done on a separate thread.
MozReview-Commit-ID: 7CKDBqUsLny
--HG--
extra : rebase_source : 45b608544b4ddf8502302cf974ca4e8b306de64e
Although they still happen in the same transaction, they are done in two
separate frame messages. This results in better encapsulated code on the
C++ side since we don't have to pass around an array of properties, and
will simplify future changes to update these properties at render time
rather than at GenerateFrame time.
MozReview-Commit-ID: 9qUkHX7gmD1
--HG--
extra : rebase_source : 15a319ba270eb1783815c514ae05c6a72e323dac
This makes webrender much less verbose in release builds, and also
feeds all printing through a single managed point. This is intended
to reduce the amount of crashes we get from stdout becoming unavailable
on users' machines.
With this commit, all the auto-dir scrolling functionalities are completed in
APZ.
MozReview-Commit-ID: L7qa3xOD8t9
--HG--
extra : rebase_source : bad2770219a0e6219f91899ab6c78e68f37195ac
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
This was only recently made possible by webrender#2600, which introduced special stacking-context
clips
MozReview-Commit-ID: HQAU7IsfDaz
--HG--
extra : rebase_source : 0ac7f0f3f73abdf5b60ca02b37cfaa7abeecb6a3
This changes the code around mFollowing group size changes to match
the code in DoGroupingForDisplayList. Specifically, it makes sure
we always ClearItems() on size changes even if we don't have a key.
Instead of passing a WrPipelineInfo* to C++ code, we can now pass the
WrPipelineInfo directly. C++ code can access the info members without
having to call back into rust code, so the wr_pipeline_info* iterator
methods can be removed. Deleting the structure still requires passing it
back to rust.
MozReview-Commit-ID: HYcPX3mCGKW
--HG--
extra : rebase_source : f4b781cfc463c8e196f67a6e178ce4ce44a9464a
This structure makes it more ergonomic to access vectors from C++. A
Vec<T> can be converted to FfiVec<T> which can safely cross the FFI
boundary. That provides an easy to use read-only access mechanism to the
vector contents. The FfiVec must be returned to rust code to be freed
properly.
MozReview-Commit-ID: AdIyEsjrPSZ
--HG--
extra : rebase_source : db87eb55e19c2d129f4c8a8155b03d9fbfc98199
This changes the code around mFollowing group size changes to match
the code in DoGroupingForDisplayList. Specifically, it makes sure
we always ClearItems() on size changes even if we don't have a key.
--HG--
extra : rebase_source : 2063974082862906a2831bdd76ac86871ee3dbc3
This allows us to treat tasks from different layers id as independent,
thereby removing the unnecessary latency increase as described in bug
1449982 comment 33.
Note that we could probably implement this by actually maintaining
separate queues for each layers id, but that involves more overhead
since we would need to have a map from layers id to task queue, and
removing entries from that map becomes tricky with respect to locking
and timing.
MozReview-Commit-ID: 7jtYqNDwJqP
--HG--
extra : rebase_source : d55fa2c20c5e78a330033dcf049d5cc468024bb0
This makes it so that we only process a UpdateHitTestingTree task (and any
tasks queued after it) once we know that the corresponding scene has
been built and swapped in by WebRender. This ensures that processing of
APZ data stays in sync with the active scene in WR.
The way we do this is by tracking the "epoch" (which is updated per
WR/layers transaction) that the APZ messages are based on. Only once the
scene for that transaction is swapped in do we process those messages.
MozReview-Commit-ID: 2qGTSTeSqve
--HG--
extra : rebase_source : fb4cb0df3970213d01e21a792957ad22771a0637
This allows us to easily store a handle to the APZUpdater on the
WebRenderScrollDataWrapper class and walk around in the scroll data tree
without having to query other classes like CompositorBridgeParent or
WebRenderBridgeParent when we encounter a reflayer boundary.
MozReview-Commit-ID: 6l7oMb7tBlW
--HG--
extra : rebase_source : d21b64317eaf40f743fb7354b3292ab0f54a6d05
I don't know why we keep using plain uint32_t and uint64_t values when
we have better types that we can use. This makes the code use and store
wr::Epoch natively instead of raw uint32_t values that are wrapped
on-demand.
MozReview-Commit-ID: HUVcHYSxBTi
--HG--
extra : rebase_source : 9e8f367f864483a65273cbbeb1168587841279f0
If we're using the WR scene builder thread as the updater thread, we
cannot just post a task to its message loop, because it's a rust thread
that doesn't have a message loop. Instead, we put these tasks into a queue
that we will process in callbacks that are invoked from the updater
thread.
This patch just adds the basic queue machinery, it will get more
complicated in a future patch because we need to gate the tasks to make
sure they don't run too early.
MozReview-Commit-ID: 8DCYbsQ5cBC
--HG--
extra : rebase_source : 7081fb187436451b0c9d654f2e31c486d25924d7
