SurfaceWithFormat has a constructor that takes a raw pointer to a refcounted
gfxSurfaceDrawable. It turns out that every single callsite passes in a
freshly-allocated gfxSurfaceDrawable for this parameter, expecting the
SurfaceWithFormat to take ownership of this object.
This patch formalizes that pattern, by changing the param type to
already_AddRefed<gfxDrawable> instead of being a raw pointer. This formalizes
the lifetime/memory-safety guarantees for that object -- it closes the window
where we were passing around a zero-refcount-object that could be deleted out
from under us if someone happened to touch it before it made it into a
persistent RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D299035
Replaces `MOZ_BIG_ENDIAN()` with testing for `std::endian::native == std::endian::big`. In
statement contexts `if constexpr` is used to mark the condition as a compile-time constant.
The only remaining `MOZ_BIG_ENDIAN()` uses are in "modules/fdlibm/src/math_private.h"
and will get updated in parts 4-5.
Adds explicit includes to "mozilla/EndianUtils.h" for files which previously
only transitively included it through "mozilla/HashTable.h".
Differential Revision: https://phabricator.services.mozilla.com/D288177
This reverts commit 5d8e0746eb.
Revert "Bug 2023878 - Part 6: Remove MOZ_LITTLE_ENDIAN and MOZ_BIG_ENDIAN. r=sergesanspaille"
This reverts commit 634b3e1287.
Revert "Bug 2023878 - Part 5: Reimport fdlibm with updated patches. r=sergesanspaille"
This reverts commit 5ed2376e75.
Revert "Bug 2023878 - Part 4: Replace MOZ_LITTLE_ENDIAN and MOZ_BIG_ENDIAN in fdlibm. r=sergesanspaille"
This reverts commit 36dad49d5b.
Revert "Bug 2023878 - Part 3: Replace MOZ_LITTLE_ENDIAN uses with std::endian::little. r=sergesanspaille,media-playback-reviewers,padenot"
This reverts commit e89c61d064.
Revert "Bug 2023878 - Part 2: Replace MOZ_BIG_ENDIAN uses with std::endian::big. r=sergesanspaille,media-playback-reviewers,profiler-reviewers,canaltinova,padenot,necko-reviewers,dom-storage-reviewers,jesup"
This reverts commit be3c506fcf.
Revert "Bug 2023878 - Part 1: Use std::endian for mozilla::detail::Endianness. r=sergesanspaille"
This reverts commit dc96d4abe8.
Replaces `MOZ_BIG_ENDIAN()` with testing for `std::endian::native == std::endian::big`. In
statement contexts `if constexpr` is used to mark the condition as a compile-time constant.
The only remaining `MOZ_BIG_ENDIAN()` uses are in "modules/fdlibm/src/math_private.h"
and will get updated in parts 4-5.
Adds explicit includes to "mozilla/EndianUtils.h" for files which previously
only transitively included it through "mozilla/HashTable.h".
Differential Revision: https://phabricator.services.mozilla.com/D288177
Now that we support gcc starting with version 10 and clang starting with
version 17, we can solely rely on __builtin_(mul|add|sub)_overflow for
CheckedInt implementation. This greatly simplifies the implementation.
Also tidy up includes as a side effect.
Differential Revision: https://phabricator.services.mozilla.com/D266655
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
An image container can keep a surface alive longer than it can remain in
the cache, if it is indeed kept in the cache. We should cross reference
our memory report generated from the SurfaceCache against any surfaces
stored in our ImageContainer objects to ensure they are all reported.
This is of particular importance for blob recordings which are not put
into SurfaceCache. While the recordings themselves have their own memory
reporting inside of WebRender, it would be good to know what recordings
we are keeping alive from the content side to help break it down.
Differential Revision: https://phabricator.services.mozilla.com/D115517
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
We can perform the same function as RecyclingSourceSurface by checking
the ref count of the underlying surface directly. We need to ensure
WebRender is explicitly aware that it is a recycled surface, but that is
easily achieved by changing the type of the surface. This avoids
unnecessary heap allocations, particularly in the case where many
elements on the same page refer to the same animation (and thus
duplicating RecyclingSourceSurface objects).
Differential Revision: https://phabricator.services.mozilla.com/D77513
We are seeing some crash reports with RecyclingSourceSurface containing
null pointers in the signature. The proto signature doesn't make any
sense however. Let's use NotNull to reassure ourselves that there isn't
something going wrong when we create RecyclingSourceSurface.
Differential Revision: https://phabricator.services.mozilla.com/D64066
This patch adds reporting the surface types used by the image frame in a
bit mask (such if it is a CAPTURE including a DATA_SHARED, the mask will
be 1 << CAPTURE | 1 << DATA_SHARED), as well as an estimated size
included in the report as decoded-unknown for when we do not know if the
surface is on the heap or the non-heap specifically. This is the default
implementation for a SourceSurface as well, so we should no longer have
the case where surfaces appear empty despite being in the cache. It also
makes requests being validated as always notable for reporting purposes.
Differential Revision: https://phabricator.services.mozilla.com/D61458
This dumps more information about the surface cache. Each surface has a
flag indicating whether or not it has finished decoding; incomplete
surfaces are now marked as such in the cache reports. We now also have
counters for various insertion errors, as well as the composition of the
cache (total vs locked images, total vs locked surfaces).
Differential Revision: https://phabricator.services.mozilla.com/D60450
When one uses SourceSurfaceRawData to wrap a data pointer, it will
perform a copy of said data if GuaranteePersistence is called. This is
done for DrawTargetCapture, which is used with OMTP. Prior to this
patch, image surfaces would be wrapped by a SourceSurfaceRawData when
using the basic compositor on any non-Linux platform (since Linux does
not support volatile memory). This means every time imgFrame::Draw is
called with OMTP, a copy of the image will be made. Images don't need
this property since the data is already going to persist, so this patch
adds a new class SourceSurfaceMappedData, which takes a ScopedMap
keeping the underlying surface open and readable.
Differential Revision: https://phabricator.services.mozilla.com/D58199
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
Daniel Holbert