The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
SharedSurface_SurfaceTexture::ProducerReadReleaseImpl() handles java::GeckoSurfaceTexture. But how it work is very confusing. The GeckoSurfaceTexture is not SurfaceTexture of this class's GeckoSurface when current process is content process. SurfaceTexture of this class's GeckoSurface does not exist in this process. It exists in compositor's process. Then GeckoSurfaceTexture in this process is a sync surface that copies back the SurfaceTextrure from compositor's process.
Call ReleaseTexImage() only when Surface is single buffer mode, since it needs to be called only when Surface is single buffer mode.
Differential Revision: https://phabricator.services.mozilla.com/D84477
Previously, any time a text run was requested where the number of
glyphs to rasterize was < 8, WR would rasterize those glyphs on
the main backend thread.
However, this pattern (along with skipping glyphs in the text run
that are already cached) meant that we will often see frames where
almost all of the glyph raster work gets done on the main thread,
even when there are a large number of glyphs to rasterize.
This patch introduces a batching system. Any time a batch of 8
glyphs for a given font instance are queued, they are dispatched
to a worker thread. At the end of the glyph request phase, any
pending glyphs are also sent to worker threads, if there is a
significant amount of work to do, or done on the main thread if
there are only a few glyphs left.
During profiling of a number of common pages, this appears to drop
the mean and median frame building time by a small amount, but drop
the worst case frame building times by significant amounts (often
several ms).
Differential Revision: https://phabricator.services.mozilla.com/D89692
Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
This helper method abstracts over the common tasks performed in every normal
shutdown codepath. This will be useful for making process recycling respect
preallocation being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D88627
It is uncommon to have long-lived "web" processes when Fission is enabled, so in
general we probably don't want to be performing content process recycling.
We also skip recycling web processes when E10s is disabled, as the process
preallocator would be disabled in that case, so recycling processes can lead to
mochitest-chrome test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88626
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
We were adding the unwriteable to the default margin. I was going to
consider not painting the headers / footers if they overlapped with the
content box of the page, but turns out our default configuration
overlaps slightly at the bottom, so I just punted on that.
Users can remove the headers / footers quite easily anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D89794
