By using the destination DT we will use the correct offset
during playback instead of the offset of the reference target.
Differential Revision: https://phabricator.services.mozilla.com/D68495
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68152
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
The texture array is currently grown layer by layer and we typically get to 3 or 4 layers over several frames by the time we are done loading a simple wikipedia page.
Differential Revision: https://phabricator.services.mozilla.com/D68056
--HG--
extra : moz-landing-system : lando
The current heuristic in TextureCache::maybe_reclaim_shared_memory pretty much clears the cache every 5 seconds. Clearing the cache is prtty drastic though, because it causes us to re-upload data and reallocate several textures on the next frame. We really only want to do it when the savings are big, which happens less often now that texture array layer count is capped at 16 and that textures are released as soon as they are empty.
This makes us clear the cache less often by augmenting the threshold to 16 megabytes and only considering texture regions that would not be reallocated right away (since we grow some texture arrays more than one region at a time).
Differential Revision: https://phabricator.services.mozilla.com/D68051
--HG--
extra : moz-landing-system : lando
We already have a cooldown from texture cache items being deallocated a certain amount of time and frames after their last use so we can deallocate texture arrays as soon as they are completely empty. We do this at the end of the frame to avoid deallocating and reallocating within the frame. It's better to reclaim texture memory this way than run into maybe_reclaim_shared_memory which will throw away everything and cause new allocations on the next frame.
Differential Revision: https://phabricator.services.mozilla.com/D68050
--HG--
extra : moz-landing-system : lando
Support hiding slices to better understand what's on which layer,
and to hide UI when not relevant.
Requires using a HTTP server due to cross-scripting.
Differential Revision: https://phabricator.services.mozilla.com/D67963
--HG--
extra : moz-landing-system : lando
When we calculate the repeating tile size, errors can be introduced,
such that there are cases it should be the same as the bounds, but is
slightly different. This can cause a new repetition where we did not
expect one. This patch makes the comparison when may force the tile size
to be the same as the snapped bounds more fuzzy.
Differential Revision: https://phabricator.services.mozilla.com/D67620
--HG--
extra : moz-landing-system : lando
This is no longer as important, with picture caching. Removing it
will simplify the planned changes to switch to a simpler segment
model based on nine-patch rectangles during scene building.
Differential Revision: https://phabricator.services.mozilla.com/D67792
--HG--
extra : moz-landing-system : lando
Previously, we kept the object IDs managed on content side only.
The GPU side would work with given indices.
When an object is destroyed, we'd free the ID on the content side and signal the GPU to delete the object.
Problem is that on the GPU process the object may still be kept alive for as long as any dependants are alive.
What this change is doing - hooking up the callbacks to the *actual* freeing of IDs on the GPU side.
These callbacks end up in messages from WebGPUParent to WebGPUChild, and only then the IDs are freed
on the content side and able to be reused.
Differential Revision: https://phabricator.services.mozilla.com/D67211
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 622591504941 (bug 1616901)
Backed out changeset 034d885d32cb (bug 1623777)
Backed out changeset 610fe9c88f2e (bug 1623647)
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
So that accesses that use mSkipRect.XMost() - 4 or - 16 are aligned to a 4-byte
boundary. Not doing so would crash on some architectures due to a SIGBUS.
Differential Revision: https://phabricator.services.mozilla.com/D66748
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
Jeff Muizelaar
Bert Peers
Chris Peterson
Nicolas Silva
Lee Salzman
Jonathan Kew
Razvan Maries
Chris Martin
sotaro
cbrewster
Andrew Osmond
Botond Ballo
Daosheng Mu
Kartikaya Gupta
Glenn Watson
Dzmitry Malyshau
Sylvestre Ledru
Mihai Alexandru Michis
Brindusan Cristian
Gabriele Svelto
Emilio Cobos Álvarez
Simon Giesecke