Reject software rasterizers on Linux (except Software WebRender) when
trying to create full WebRender, unless WebRender was force enabled.
Differential Revision: https://phabricator.services.mozilla.com/D117534
The clear region prim don't support complex clip regions (the
complex clip region was being ignored). This has been shipping
like this for many months now, so it seems it's not required.
Differential Revision: https://phabricator.services.mozilla.com/D114563
WebRenderAPI::DestroyRenderer() destroys RendererOGL and WebRender's Renderer instance. After RendererOGL is destroyed, RenderBackend could not sent message to WebRender's Renderer via RenderBackend::result_tx.
Message sending by RenderBackend::result_tx needs to be stopped after destroying WebRender's Renderer instance.
After wr_api_stop_render_backend() call, RemoveRenderer have to be called via wr_api_send_external_event(). It actually destroys the renderer. Its message arrives when WR backend is in RenderBackendStatus::StopRenderBackend state. At the time, WR backend is stopped sending message to renderer.
Differential Revision: https://phabricator.services.mozilla.com/D110795
Root WebRenderBridgeParent's ClearResources() call is expected to destroy RenderCompositor. It is necessary to avoid conflict between RenderCompositors and to avoid use after free.
Differential Revision: https://phabricator.services.mozilla.com/D109693
This patch is plumbing to get a path and a flags word through from the content
process to the graphics process, to pass to `wr_api_start_capture_sequence`.
Differential Revision: https://phabricator.services.mozilla.com/D106229
We need to be able to delay instantiation of the drawing region until after we have the
dirty rects from start_compositing. This was currently not routed to RenderCompositor,
which is required to do this. Further, SwCompositor needs to always keep track of the
RenderCompositor that it is associated with regardless of whether or not it is a native
compositor so that this hook can be properly engaged.
Differential Revision: https://phabricator.services.mozilla.com/D100974
`DisplayListBuilder::PushRoundedRect`, used for unordered list bullets and the
like, draws rounded rectangles as ordinary rectangles with rounded borders that
have a radius of half the rectangle. Unfortunately, this leads to tiny white
dots at the center of the bullet under some magnifications. I haven't diagnosed
why - perhaps there's something somewhere that snaps borders outward.
Increasing the thickness of the borders to (an impossible) 60% of the width of
the rectangle makes the problem go away. If this kludge doesn't work, we could
add a rectangle covering the center.
Differential Revision: https://phabricator.services.mozilla.com/D100753
This ID allows the compositor to track per-frame information from frame
generation, through APZ sampling, to the NotifyDidRender notification.
Differential Revision: https://phabricator.services.mozilla.com/D97535
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
This patch removes the public API and high level logic for
disabling picture caching for debugging and pinch-zoom in
some cases.
Follow up patches will remove and simplify the internal parts
of WR that remain to handle the disabled picture caching
code path.
Differential Revision: https://phabricator.services.mozilla.com/D93446
When using the native RenderCompositor+SWGL on MacOS, we don't support passing buffer textures directly to the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D93179
