To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
Before this patch the embedded profiler would show the last avg/max values for a profile counter if it hasn't had samples for a long time. After this patch the counter shows 0 if there was no sample.
For example when no glyphs are rasterized there are no 'Rasterized glyphs' samples. If no glyphs are rasterized for multiple seconds then we are currently still showing the average and max number of rasterized glyphs from seconds ago which makes it look like we are constantly rasterizing glyphs. With this patch the counter goes back to zero after half a second of not rasterizing glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D122263
We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.
In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).
Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.
Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.
Changes in the patch:
- Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
- Track nsWindow compositor state by WindowCompositorState
- Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
- Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
- Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.
Differential Revision: https://phabricator.services.mozilla.com/D121650
As it's usually not very useful. I don't know how easily we can add a
reliable test for this, let me know if you come up with an idea to do
that.
Differential Revision: https://phabricator.services.mozilla.com/D122222
On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.
This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.
This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D122221
Move the extra_data to be a specific cache_data separate vec in
the display list payload.
This shouldn't change any functionality, but serves as a proof
of concept for future changes which will introduce several other
separated payload vectors.
Differential Revision: https://phabricator.services.mozilla.com/D121937
This attempts to emulate the behavior of GetRecommendedRenderingMode without
actually calling it. In addition, it allows some Gecko-specific behavior
like overriding the render mode explicitly that allows some simplification
of the decision-making.
Inside GetRecommendedRenderingMode, natural is only allowed if <= 20 size.
This allows us to thus decide mostly based on whether the size is > 20 or
if an explicit mode was specified. In the remaining case where we need
to check a GASP table if available, we defer to the symmetric flag. If
there is no GASP, we assume natural.
Differential Revision: https://phabricator.services.mozilla.com/D122025
Before this patch any item that is wider or taller than 512 pixels goes into its own standalone texture. However we often generate linear gradient tasks with a height of 1 pixels and a width between 512 and 1024. Having them in standalone textures wastes a lot of memory and breaks batches. 1024 pixels fits exactly in the linear color cache texture.
Differential Revision: https://phabricator.services.mozilla.com/D121362
We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.
Depends on D122048
Differential Revision: https://phabricator.services.mozilla.com/D122049
This patch aims to address a worst-case theoretical possibility where the job count might for
some reason get out of sync, causing either the SwComposite thread or the main thread to deadlock
waiting on jobs that may never become available.
To this end, we get rid of the job count tracking entirely, and instead just track whether,
first, the SwComposite thread has completed all the jobs that have been queued for it, and,
second, that the main thread, having completed all jobs that were available, is waiting for
jobs to be available or completed such that the SwComposite thread would need to wake it up.
The main thread does not need to wait if it knows the SwComposite thread completed all jobs,
and the SwComposite thread does not need to signal if it knows the main thread is not waiting.
Otherwise stated, so long as both the main and SwComposite threads know there are no more
available jobs, then there is no way compositing can advance any further, and so compositing
must be finished. This avoids relying on having a job count that is always accurate to track
termination.
Differential Revision: https://phabricator.services.mozilla.com/D121821
It's non WebRender specific, so it will not be a problem on Fission,
additionally it's not used on non WebRender with retained display stuff
either.
Differential Revision: https://phabricator.services.mozilla.com/D121929
This provides settings, which are populated from gfxVars retrieved in the
parent, so that they can be used in all processes.
IDWriteRenderingParams are created lazily, so that we don't try and create them
in processes that have win32k locked down where the API calls will fail.
Differential Revision: https://phabricator.services.mozilla.com/D120597