WebGPU itself doesn't care about WebRender or even the GPU process.
However, the presentation to canvas as written today only works with WebRender, so
it seems fine to have it as a dependency in general.
An alternative could be to just fail getContext() call if webrender is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D70888
This is a somewhat speculative fix, as I haven't been able to reproduce the issue locally,
but it seems like the right thing to do given that (AFAIK) the DirectWrite APIs don't
make any promises about consistent ordering of faces within the list.
Differential Revision: https://phabricator.services.mozilla.com/D97043
This is a somewhat speculative fix, as I haven't been able to reproduce the issue locally,
but it seems like the right thing to do given that (AFAIK) the DirectWrite APIs don't
make any promises about consistent ordering of faces within the list.
Differential Revision: https://phabricator.services.mozilla.com/D97043
This allows adding another vsync listener that gets called before the regular VsyncSource.
And it allows adding the listener on the Java UI thread.
The existing infrastructure is pretty adamant about being used on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D96797
This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
This makes the vsync times more consistent.
On a Pixel 2 running Android 11, the callback was called between 1ms and 6ms
after the vsync timestamp in my tests. Having the vsync timestamp slightly in
the past is what the rest of our vsync infrastructure expects.
Differential Revision: https://phabricator.services.mozilla.com/D96279
Currently we upload texture data by first splitting the updates based
on their destination texture. Then we iterate through every update for
the texture and calculate the total required size, then allocate and
map a PBO large enough to contain the updates. Finally we fill the PBO
with the data and submit the uploads, before moving on to the next
texture. This results in a lot of allocating and mapping PBOs of
highly variable sizes, and also requires an extra iteration of the
updates to calculate the required size.
This change makes it so that we allocate fixed size PBOs. We fill the
PBOs with as many updates as they have room for, then start filling a
new one. Furthermore, we recycle the PBOs to avoid having to
reallocate them, and if possible we persistently map them too.
The TextureUploader struct can now be used to upload to more than one
texture, ensuring buffers are filled more efficiently. It is also now
possible to manually stage some data in the PBO to be uploaded, in
case the client requires more fine-grained control over the layout of
the data.
If a single upload is too large to fit within the fixed-size PBO, then
we allocate a single-use larger PBO for the upload. As before, on Mac
we unfortunately must use a separate PBO for each individual upload,
so we also allocate single-use custom-sized PBOs in that case.
Differential Revision: https://phabricator.services.mozilla.com/D96024
gfxPlatformGtk needs gtk_init() so we can't use it in all places where dmabuf is used, so remove it from it.
Leave only WebGL config there as it can use gfxPlatform.
- Reomve UseDMABufTextures()
- Remove UseDMABufVideoTextures()
- Remove UseHardwareVideoDecoding()
- Remove UseDRMVAAPIDisplay()
Depends on D95992
Differential Revision: https://phabricator.services.mozilla.com/D95993
With this patch, the system font seems to work OK again on 10.15 when building Firefox with SDK10.15,
provided webrender is *disabled*. We no longer trigger the Core Text error messages from InitSystemFontNames(),
and the proper system font is used.
(With webrender, we get garbage because it fails to instantiate the system font and renders "random" Times
glyphs instead.)
Differential Revision: https://phabricator.services.mozilla.com/D95453
If there's a device error trying to read some of the data from a font, it's better to catch the exception
and leave that individual font unusable (without names or character map) than to crash the whole process.
Differential Revision: https://phabricator.services.mozilla.com/D95146
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Rather than wrapping an NSPrintInfo in nsPrintSettingsX, where we then have two
(potentially conflicting) sources of truth about various settings, we treat the
settings in the base nsPrintInfo class as authoritative, and just apply them to
a temporary NSPrintInfo when needed to interact with platform APIs.
Differential Revision: https://phabricator.services.mozilla.com/D92966
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This is a follow up from bug 1668377. It changes
some function names, comments and removes the factory
method.
The WrapAndRecord target is still used by the global recording
stuff so I've kept it for now.
Differential Revision: https://phabricator.services.mozilla.com/D92777
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
On Linux, Firefox is listening on notify::scale-factor to detect DPI
change. However, scale-factor is an int and on the lower-end side of
the DPI scale, some devices are using fractional scale factors encoded
into Xft/DPI setting. Changing from ×1 to ×1.5 scale is therefore
undetected.
The proposed change is two-folds:
- remove use of a cached sDPI value and rely on GTK being the cache
- listening on notify::gtk-xft-dpi to trigger a DPI change
What is missing:
- performance evaluation of not caching sDPI (on a 10s session
loading 2 pages, there is an "overhead" of 6ms on my setup, nothing
visible from my point of view)
- when changing Xft/DPI and scale, the change is done twice, this
seems harmless
Differential Revision: https://phabricator.services.mozilla.com/D92095
This allows mesa to continue using the existing vsync implementation
and nvidia to use the new EGL xvisual logic.
It is an intermediate solution until the issues are fixed. However,
assuming it will take a while to do so, it's probably worth it.
Differential Revision: https://phabricator.services.mozilla.com/D92466
The mathml reftest pref needs to be added at the same time because the test needs that pref with the new scrollbar code to pass, but it fails with that pref with the old scrollbar code. Since that test uses the minimum scale, which is only valid with overlay scrollbars, it is correct to do so.
Differential Revision: https://phabricator.services.mozilla.com/D91243
Using WrapAndRecord for printing was just a way to minimize risk when
working on the RecordingDrawTarget. We would prefer to eliminate
WrapAndRecord.
These leaves some of old function names around just to keep the patch
small. If it sticks we can fix those names.
Differential Revision: https://phabricator.services.mozilla.com/D91988
We also rearrange bits in the CompressedGlyph so that the advance field doesn't need to be shifted,
and remove unnecessary glyphCount parameters from various setter methods.
Differential Revision: https://phabricator.services.mozilla.com/D90678
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also rename to UNUSED_FEATURE_WEBGL_MSAA, pending removal.
Differential Revision: https://phabricator.services.mozilla.com/D91208
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also remove obsolete FEATURE_WEBGL_MSAA.
Differential Revision: https://phabricator.services.mozilla.com/D91208
The mathml reftest pref needs to be added at the same time because the test needs that pref with the new scrollbar code to pass, but it fails with that pref with the old scrollbar code. Since that test uses the minimum scale, which is only valid with overlay scrollbars, it is correct to do so.
Differential Revision: https://phabricator.services.mozilla.com/D91243
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also remove obsolete FEATURE_WEBGL_MSAA.
Differential Revision: https://phabricator.services.mozilla.com/D91208
We don't collect telemetry stats on why users don't get HW ANGLE,
however we can just share failure IDs with HW ANGLE when we disable
WebRender with UnavailableNoAngle.
Differential Revision: https://phabricator.services.mozilla.com/D90867
We need to initialize the GPU process config before WebRender because we
have a dependency on the GPU process to enable WebRender. Without this
patch, it gives very confusing initialization failures, which it should
be clear that it was disabled because there is no GPU process. The GPU
process feature itself will then have a clear reason why it was
disabled, typically because Windows did not support remote windowing
(e.g. too old).
Differential Revision: https://phabricator.services.mozilla.com/D90564
There was a weird mix of nsAutoRef and nsCountedRef going on... Use RefPtr<>
for ref-counted things, and UniquePtr for non-refcounted ones.
Differential Revision: https://phabricator.services.mozilla.com/D90400
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
AHardwareBuffer could remove several limitations of android::SurfaceTexture.
File descriptor usage of current implementation is not efficient. It is going to be addressed by Bug 1663381.
Differential Revision: https://phabricator.services.mozilla.com/D89232
Use ID3D11VideoProcessor for video frame rendering.
WebRenderError::VIDEO_OVERLAY does not cause disabling WebRender. It just change gfxVars::UseWebRenderDCompVideoOverlayWin() to false.
Differential Revision: https://phabricator.services.mozilla.com/D88763
This was left as a debug option when the original change was made,
to allow seeing the differences. It's no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D89328
When GLX Vsync source is created along EGL contexts, NVIDIA drivers refuse to make any EGL content current.
So disable GLX Vsync source creation when EGL context is used.
Differential Revision: https://phabricator.services.mozilla.com/D87634
When GLX Vsync source is created along EGL contexts, NVIDIA drivers refuse to make any EGL content current.
So disable GLX Vsync source creation when EGL context is used.
Differential Revision: https://phabricator.services.mozilla.com/D87634
AHardwareBuffer requests to handle android fences. There are 2 type of fences, release fence and acquire fence. Some ideas were borrowed from b2g's FenceHandle implementation.
The release fence is a fence that is used for waiting until usage/composite of AHardwareBuffer is ended. It needs to be delivered from host side to client side. It is delivered via ImageBridge, since some TextureClientd str recycled without recycle callback.
The acquire fence is a fence that is used for waiting until rendering to its AHardwareBuffer is completed. It is delivered from client side to host side.
Differential Revision: https://phabricator.services.mozilla.com/D87298
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
When a CompositorBridgeParent is initialized it reads the vsync duration from
the AndroidVsyncSource::Display instance. The vsync duration is currently
initialized in AndroidVsyncSource::EnableVsync(). Since bug 1617750 landed,
which makes the hidden window lazily loaded, the first tab's
CompositorBridgeParent is being initialized before vsync is enabled, meaning it
reads a value of zero.
Instead, initialize mVsyncDuration in the AndroidVsyncSource::Display
constructor.
Differential Revision: https://phabricator.services.mozilla.com/D85611
This adds a profiler-stats.txt file to captures that dumps the profiler
stats, if those are being recorded. They get recorded if the profiler is
visible, or if the (newly added) PROFILER_CAPTURE debug option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D85592
This adds a profiler-stats.txt file to captures that dumps the profiler
stats, if those are being recorded. They get recorded if the profiler is
visible, or if the (newly added) PROFILER_CAPTURE debug option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D85592
This reduces IPC traffic, and avoids the (severe) impact of file access interception
and proxying by the sandbox on DirectWrite in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D83240
I could have use apz.allow_zooming but using a separate pref means we can flip the pref to check if the new scrollbar code is the source of a regression. Also I haven't tested the code on Fenix at all, so we can disable it there for now.
Differential Revision: https://phabricator.services.mozilla.com/D82684
This timestamp is provided by the system on macOS, and estimated as "the next
vsync" on all other platforms.
On macOS, the output time increments in very consistent amounts. The timestamp
is independent of when exactly the vsync callback ends up running, so it is less
vulnerable to unfortunate thread scheduling.
This makes it a more reliable source for picking video frames, for example.
Differential Revision: https://phabricator.services.mozilla.com/D83828