This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This layer structure can still occur in cases where we place the RCD-RSF
scroll metadata on the root layer as a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D47655
--HG--
extra : moz-landing-system : lando
The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
To support NDK r20, wrench needs to be built with a more recent, upstream
(though still unpublished) version of cargo-apk. This has some consequences
which have been adjusted for:
* Gradle is no longer required to build wrench.
* The output apk file paths have changed.
* The apks are now signed automatically.
* The default activity name has changed.
* Android permissions must be explicitly requested.
* We must ensure winit is built with a matching version of android_glue.
Differential Revision: https://phabricator.services.mozilla.com/D47129
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
To avoid duplicating information, the comment about lock ordering in
APZCTreeManager.h is also updated to point to the documentation.
Differential Revision: https://phabricator.services.mozilla.com/D47146
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Before Bug 1570869, new frame was generated if WR does not have a pending frame build task. But since Bug 1570869 fix, there is a case that new frame generation does not happen even when WR does not have a frame build task.
Differential Revision: https://phabricator.services.mozilla.com/D47045
--HG--
extra : moz-landing-system : lando
Move DeviceReset handling before the assert. It is OK, since RendererOGL instance is not re-used after the DeviceReset. It is replaced by a new RendererOGL.
Differential Revision: https://phabricator.services.mozilla.com/D47036
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Still getting some crash reports on nightly with a 1MB stack. Let's try one more time
with 2MB just to see if we can eliminate those. If this fails, then we may need to consider
more drastic approaches like disabling OMTP in this case.
Differential Revision: https://phabricator.services.mozilla.com/D47080
--HG--
extra : moz-landing-system : lando
This approach does have some stacking issues. The way to fix this would
be to instrument the brush_image shader rather than adding debug rects.
Something like: #ifdef WR_FEATURE_SFW frag.color = vec4(0,1,1,1); #endif
That's slightly more involved though, so I'm going to leave it for now.
Differential Revision: https://phabricator.services.mozilla.com/D47155
--HG--
extra : moz-landing-system : lando
D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not
having the first call to ResizeReflow have a wrong old size of 0x0.
This removes the code that bug introduces to suppress resize events, which
fixes this bug. I think our behavior now is pretty sane.
In particular, consider the test-case:
<!doctype html>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<a href="" target="_blank">Open me in a separate tab</a>
<pre id="log"></pre>
<script>
// This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on
// longpress...
document.querySelector("a").href = location.href;
function logSize() {
log.innerText += window.innerWidth + "x" + window.innerHeight + "\n";
}
logSize();
onresize = logSize;
</script>
(Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience)
Right now on trunk, when you click the link from GVE or Fenix, we're only
getting an initial size of 0x0 (which is not great, btw), and only after first
paint we get the real device size, but content doesn't get a resize event.
This is obviously wrong, every time the layout viewport changes we should fire
resize events.
Pages that get opened in new tabs and get refreshed when resized may get an
extra reload with this approach, but this seems not avoidable unless widget sets
the viewport size right in advance (which from discussion with snorp and agi
doesn't seem possible in the general case).
What used to happen is that we were triggering a redundant resize reflow from
the initial paint which didn't update the layout viewport (because the content
viewer and co had the right viewport from the previous navigation).
Now that we optimize those away, I think our behavior should be correct.
Differential Revision: https://phabricator.services.mozilla.com/D46956
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando
It is a preparation of Bug 1460499. It adds RenderDXGITextureHostOGL::GetD3D11Texture2D() for use by dc layer.
Differential Revision: https://phabricator.services.mozilla.com/D46928
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
Let's use single Wayland configuration point at gfxPlatformGtk instead of various GDK_IS_X11_DISPLAY() calls.
Also provide info about enabled DMABuf surfaces when Wayland backend is used.
Depends on D46842
Differential Revision: https://phabricator.services.mozilla.com/D46843
--HG--
extra : moz-landing-system : lando
WaylandDMABufSurface is used as a backend for WaylandDMABUFTextureHostOGL.
Pixel data of WaylandDMABufSurface are located at GPU memory and are
binded from WaylandDMABUFTextureClientOGL.
WaylandDMABufSurface can be binded as EGLImage so EGLImageTextureSource is used.
Depends on D46836
Differential Revision: https://phabricator.services.mozilla.com/D46837
--HG--
extra : moz-landing-system : lando
WaylandDMABufSurface is used as a backend for WaylandDMABUFTextureClientOGL.
Pixel data of WaylandDMABufSurface are located at GPU memory and can be
shared by processes.
Differential Revision: https://phabricator.services.mozilla.com/D46836
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
Let's use single Wayland configuration point at gfxPlatformGtk instead of various GDK_IS_X11_DISPLAY() calls.
Also provide info about enabled DMABuf surfaces when Wayland backend is used.
Depends on D46842
Differential Revision: https://phabricator.services.mozilla.com/D46843
--HG--
extra : moz-landing-system : lando
WaylandDMABufSurface is used as a backend for WaylandDMABUFTextureHostOGL.
Pixel data of WaylandDMABufSurface are located at GPU memory and are
binded from WaylandDMABUFTextureClientOGL.
WaylandDMABufSurface can be binded as EGLImage so EGLImageTextureSource is used.
Depends on D46836
Differential Revision: https://phabricator.services.mozilla.com/D46837
--HG--
extra : moz-landing-system : lando
WaylandDMABufSurface is used as a backend for WaylandDMABUFTextureClientOGL.
Pixel data of WaylandDMABufSurface are located at GPU memory and can be
shared by processes.
Differential Revision: https://phabricator.services.mozilla.com/D46836
--HG--
extra : moz-landing-system : lando
Adds a module documentation in segment.rs giving an overview of the role of primitive segments and how they interact with clipping. Also reformatted the clip.rs documentation to play well with rustdoc.
Differential Revision: https://phabricator.services.mozilla.com/D46472
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
Adds a module documentation in segment.rs giving an overview of the role of primitive segments and how they interact with clipping. Also reformatted the clip.rs documentation to play well with rustdoc.
Differential Revision: https://phabricator.services.mozilla.com/D46472
--HG--
extra : moz-landing-system : lando
During metrics initialization we load a few uncached glyph widths which can occasionally
show up in a profile. This should reduce the overhead of that somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D46786
--HG--
extra : moz-landing-system : lando
Fix scissor rect being incorrect during pinch zoom due to floating
point inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D46743
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
This update brings in several bugfixes and compatibility with newer
libstdc++ versions.
Differential Revision: https://phabricator.services.mozilla.com/D45860
--HG--
extra : moz-landing-system : lando
This also changes CompositorBridgeChild to create the CanvasChild lazily.
Depends on D44154
Differential Revision: https://phabricator.services.mozilla.com/D44873
--HG--
extra : moz-landing-system : lando
If VR process haven't launched yet, we couldn't get available VR displays and its states, so we need to make enumationCompleted to be false, and ask it do the enumeration again.
Differential Revision: https://phabricator.services.mozilla.com/D46238
--HG--
extra : moz-landing-system : lando
Preparation work for adding DirectComposition support. It does not add a new functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46429
--HG--
extra : moz-landing-system : lando
We only use the png codec so let's save some link time by not including
the other codecs.
Differential Revision: https://phabricator.services.mozilla.com/D46317
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
IDCompositionDevice::Commit needs to be called when there is an update to DirectComposition. RenderCompositorANGLE updates DirectComposition only during initialization. Then it is not necessary to call the function in EndFrame().
Differential Revision: https://phabricator.services.mozilla.com/D46249
--HG--
extra : moz-landing-system : lando
This fixes a case where the is_same_content field was no longer
being reset to true before dependency calculation could occur.
In some cases, this could result in a tile being updated, but
the dirty rect being empty, which meant all primitives in that
tile would fail the visibility culling test.
Differential Revision: https://phabricator.services.mozilla.com/D46247
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
This provides the internal device-space dirty rects calculated
during picture cache updates to the external render() method.
This allows clients to provide these to OS partial present APIs,
to reduce power usage and improve performance.
In this initial implementation, if a scroll or scale of the main
picture cache has occurred, the dirty rect will be the entire
screen. This should ensure correctness. In future, we can handle
this case by supplying the picture cache transforms to the OS
compositor integration.
However, the dirty rects will be valid for any non-scroll cases,
such as animations or video playback. This should result in some
significant power savings and performance improvements for these
use cases.
Differential Revision: https://phabricator.services.mozilla.com/D46082
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
This works by keeping track of the previous visible rect and
computing a preserved rect by intersecting with the new visible
rect.
We force the dirty rect to be inside this preserved area.
Differential Revision: https://phabricator.services.mozilla.com/D45284
--HG--
extra : moz-landing-system : lando
Previously after RecvResumeAndResize() we would set a flag on the root
WebRenderBridgeParent, which in turn sets a flag on the next display list it
receives that it should be treated as a first paint. Then when that display list
is finally composited, we call UiCompositorControllerParent::NotifyFirstPaint(),
which in turn tells GeckoView to uncover the widget.
After switching tabs in GeckoView browsers, however, the root
WebRenderBridgeParent does not always receive a new display list, so the widget
would not be uncovered. Instead of waiting for the next received display list to
be composited, we simply want to uncover the widget on the next composite. To
achieve this we instead set the forced-first-paint flag on the root
CompositorBridgeParent then we call NotifyFirstPaint() during
CompositorBridgeParent::NotifyPipelineRendered().
Differential Revision: https://phabricator.services.mozilla.com/D46157
--HG--
extra : moz-landing-system : lando
We compute the preserved bounds for each item and see if it's
contained in the invalid area. The gecko side will do the same
computation.
Appologies for duplicating euclid with Box2d type. We can deal with
that in a followup.
The asserts are disabled for now. I tried reenabling them and they
triggered. I haven't had a chance to figure out if they are still
valid.
Differential Revision: https://phabricator.services.mozilla.com/D45283
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
