In this case, the same marker type "CONTENT_FULL_PAINT_TIME" is used in separate places, so it makes sense to put the marker type definition in a common location.
Differential Revision: https://phabricator.services.mozilla.com/D96042
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
This backs out part of bug 1656211 which turned out to be insufficient.
The invalidate rendered frame transaction races with the initial frame
rendering of the popup. If it comes in too soon, we will only draw the
frame once, and the frame corruption remains. This patch makes us flush
the rendering pipeline to ensure we get two separate generate frame
events.
Differential Revision: https://phabricator.services.mozilla.com/D96157
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
Bug 1656211 added WebRenderBridgeParent::RecvForceComposite(). It triggers generate frame even when widget is not ready for rendering.
Differential Revision: https://phabricator.services.mozilla.com/D94553
Similar to bug 1280653, it appears that GLX invalidates the back buffer
while we are drawing. The only indication we get of this are resize and
configure events from X. We suppress the configure event for popups for
various reasons, so this patch explicitly generates a forced recomposite
of the frame. It does it immediately so that most of the time it should
beat the presentation of the buffer and avoid displaying of the bad
frame to the user; popups generally are not complicated and should have
plenty of budget to perform the second composite.
Differential Revision: https://phabricator.services.mozilla.com/D93862
In a (large-ish) nutshell:
- Consolidate all counters under a single type.
- Counters are all arranged in an array and referred to via index.
- All counters can be displayed as average+max (float/int), graph, and change indicator.
- Specify what to show and in what form via a pref.
- All counters and visualizations support not having values every frame.
- GPU time queries visualization is easier to read relative to the frame budget:
- If the maximum value is under 16ms, the right side of the graph is fixed at 16ms.
- If the maximum value is above 16ms, draw a vertical bar at 16ms.
- Added a few new profile counters:
- Total frame CPU time (from API send to the end of GPU command submission).
- Visibility, Prepare, Batching and Glyph resolve times.
The main change is how profile counters are represented. Instead of having different types for different visualizations, every counter is represented the same way, tracking average/max values over half a ms and optionally recording a graph over a number of frames. Counters are stored in a vector and referred to via index (See constants at the top of profiler.rs).
The main motivation for this storage is to facilitate adding counters without having to think too much about where to store them and how to pass them to the renderer.
The profiler's UI is defined by a string with with a single syntax:
- Comma separated list of tokens (leading and trailing spaces ignored), which can be:
- A counter name:
- If prefixed with a '#' character, the counter is shown as a graph.
- If prefixed with a '*' character, the counter is shown as a change indicator
- By default (counter name without prefix), the counter is shown as average and max over half a second.
- A preset name:
- A preset is a builtin UI string in the same syntax that can be nested in the main UI string.
- Presets are defined towards the top of profiler.rs and can also refer to other presets.
- An empty token adds a bit of vertical space.
- A '|' token begins a new column.
- A '_' token begins a new row.
Differential Revision: https://phabricator.services.mozilla.com/D93603
In a (large-ish) nutshell:
- Consolidate all counters under a single type.
- Counters are all arranged in an array and referred to via index.
- All counters can be displayed as average+max (float/int), graph, and change indicator.
- Specify what to show and in what form via a pref.
- All counters and visualizations support not having values every frame.
- GPU time queries visualization is easier to read relative to the frame budget:
- If the maximum value is under 16ms, the right side of the graph is fixed at 16ms.
- If the maximum value is above 16ms, draw a vertical bar at 16ms.
- Added a few new profile counters:
- Total frame CPU time (from API send to the end of GPU command submission).
- Visibility, Prepare, Batching and Glyph resolve times.
The main change is how profile counters are represented. Instead of having different types for different visualizations, every counter is represented the same way, tracking average/max values over half a ms and optionally recording a graph over a number of frames. Counters are stored in a vector and referred to via index (See constants at the top of profiler.rs).
The main motivation for this storage is to facilitate adding counters without having to think too much about where to store them and how to pass them to the renderer.
The profiler's UI is defined by a string with with a single syntax:
- Comma separated list of tokens (leading and trailing spaces ignored), which can be:
- A counter name:
- If prefixed with a '#' character, the counter is shown as a graph.
- If prefixed with a '*' character, the counter is shown as a change indicator
- By default (counter name without prefix), the counter is shown as average and max over half a second.
- A preset name:
- A preset is a builtin UI string in the same syntax that can be nested in the main UI string.
- Presets are defined towards the top of profiler.rs and can also refer to other presets.
- An empty token adds a bit of vertical space.
- A '|' token begins a new column.
- A '_' token begins a new row.
Differential Revision: https://phabricator.services.mozilla.com/D93603
Currently, when webrender fails to render a frame on time, it will
attempt to catch up by rendering the next frame immediately (part way
through the vsync period) rather than delaying until the next
vsync. The idea is that even though the first frame missed vsync, the
next frame can hopefully still be rendered on time.
However, on Android, because of the default EGL swap interval of zero,
the driver blocks rather than allowing 2 frames to be rendered in a
single vsync. This guarantees that the next frame will also miss its
vsync, and so on. Other platforms may avoid this by setting the swap
interval to zero. While that was an option on Android too, it was felt
that the premise of catch up composites was still flawed: a
late-started composite is unlikely to meet its deadline, even if the
driver does not block. Better to cut our losses and wait for the next
vsync.
Differential Revision: https://phabricator.services.mozilla.com/D92958
This is mostly preparing for the future state where we might have SWGL WR mixed with real hardware webrender, and want a way to lookup the state per-compositor.
Differential Revision: https://phabricator.services.mozilla.com/D92009
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This is mostly preparing for the future state where we might have SWGL WR mixed with real hardware webrender, and want a way to lookup the state per-compositor.
Depends on D92008
Differential Revision: https://phabricator.services.mozilla.com/D92009
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
Since the compositor can be paused at any time (due to window state changes),
it's possible (and tests confirm it can happen) that `RecvGetSnapshot` is called
while the compositor is paused. This change removes the assertion and instead
skips the snapshot work in this case.
Depends on D85955
Differential Revision: https://phabricator.services.mozilla.com/D90587
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
We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
The main change is removing ProfileJSONWriter.cpp, making ProfileJSONWriter.h point at BaseProfileJSONWriter.h, and exposing `mozilla::baseprofiler::` classes in the top namespace as expected by users of ProfileJSONWriter.h (to minimize changes).
These two headers are now always present in the "mozilla" include directory, independent of MOZ_GECKO_PROFILER settings.
The rest is just needed tweaks to match the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D86504
This makes the sample time more "strongly typed" by using a variant-style
class instead of a raw TimeStamp. The sample time can come from different
sources (vsync, testing, Now()) and it is useful to save that information
as we pass around the sample time. It would have been helpful with some
of the debugging I did recently, and it also is needed for the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D86244
This moves the IPC mechanism from PCompositorBridge to PLayerTransaction/
PWebRenderBridge, so that it can be used by content processes like the other
test APIs. It still only produces actual data for the layers backend; for
WR it will just return empty datasets.
Differential Revision: https://phabricator.services.mozilla.com/D86016
Previously, the content_size was used when defining an iframe
to set the size of the root scrollable area.
However, this was never useful (the root pipeline scroll frame
is not considered a scroll root, it's more of a placeholder).
The scroll frame for content is typically defined within the
iframe display list (which also allows non-scrolled content
within the iframe, such as a background rectangle color).
The existing content_size was causing problems in Gecko because
there are some snapping / rounding inaccuracies with fractional
DPI ratios, resulting in root scroll frames with +/- 1 pixel
scrollable size.
The simplest fix for this is to remove content_size altogether
and rely on the iframe display item to define the content size
of the root scroll frame for a pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D85719
