This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
GPUVideoTextureHost::NumSubTextures() returns 0 when wrapped TextureHost does not exist. In this case, we do not have a content of GPUVideoTextureHost for WR render. And EnsureWrappedTextureHost() calling is added in GPUVideoTextureHost::NumSubTextures(), since GPUVideoTextureHost is not explicit about when a wrapped TextureHost is created.
Differential Revision: https://phabricator.services.mozilla.com/D39137
--HG--
extra : moz-landing-system : lando
looks like a typo that got unnoticed? I wonder how our alpha saved tasks work today :)
Differential Revision: https://phabricator.services.mozilla.com/D39021
--HG--
extra : moz-landing-system : lando
`sGfxLogLevel` is a global variable whose value mirrors the value of the
"gfx.logging.level" pref in the prefs table, and is kept up to date by a
prefs callback.
But "gfx.logging.level" is a static pref that already has a mirror variable,
accessible via `StaticPrefs::gfx_logging_level()`.
So we can use the latter and remove the former, and this patch does that. The
patch also removes a sentence in a comment that refers to special treatment of
LOG_DEBUG and LOG_DEBUG_PRLOG, because that sentence appears to be referring to
something (another comment?) that is no longer present.
Differential Revision: https://phabricator.services.mozilla.com/D35625
--HG--
extra : moz-landing-system : lando
The RemoveShaderCacheFromDiskIfNecessary() needs to be called after WebRenderConfig initialization.
Differential Revision: https://phabricator.services.mozilla.com/D38978
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This patch fixes a couple of picture caching issues that could
cause more invalidations than required. Specifically:
* Ensure the viewport rect is included in child surfaces, so
that redundant clips are filtered out correctly.
* Use epsilon comparisons where appropriate for tile descriptor
comparisons, to avoid invalidations due to float inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D38455
--HG--
extra : moz-landing-system : lando
The code to batch preserve-3d elements was incorrectly using the
bounds and visibility mask from the parent element. This could
result in batching bugs in some cases, which were showing up as
draw order issues.
Differential Revision: https://phabricator.services.mozilla.com/D38834
--HG--
extra : moz-landing-system : lando
This is done my adding two new canvas RecordedEvents, which add and remove the
SourceSurfaceCanvasRecording as an alias to the SourceSurfaces that they wrap.
Differential Revision: https://phabricator.services.mozilla.com/D37089
--HG--
extra : moz-landing-system : lando
This also fixes the CanvasParent destruction on channel close and error,
which was broken due to IPDL changes between rebases.
Differential Revision: https://phabricator.services.mozilla.com/D37088
--HG--
extra : moz-landing-system : lando
A few potential error cases were being unwrapped, resulting in a very
small number of crashes. These errors can be safely ignored as the
program cache is non-critical, so this change makes us log the error
and continue rather than panicking.
Differential Revision: https://phabricator.services.mozilla.com/D38650
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This better distinguishes it from the pref name part of the getter, which uses
snake case.
Differential Revision: https://phabricator.services.mozilla.com/D38603
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
Minor things to ease the transition to StaticPrefList.yaml.
- Rename apz_touch_drag_enabled() to the correct apz_drag_touch_enabled(), and
media_mwf_low_latency_force_disabled() to the correct
media_wmf_low_latency_force_disabled().
- Change some trailing C-style comments to C++-style comments. This makes life
easier for the script I wrote to convert StaticPrefList.h to
StaticPrefList.yaml, which will be used for the next patch.
- Avoid comments on #define lines, because they aren't handled in the YAML
input.
- Convert a multi-line `#if` condition to a single line, because
Preprocessor.py doesn't handle multi-line conditions.
- Remove one unnecessary `#undef PREF_VALUE` directive.
- Move intl.charset.detector.iso2022jp.allowed to the correct section, so the
YAML processing script won't complain.
- Change an `int` pref to `int32_t`, again so the YAML processing script won't
complain.
- Change OS_OPENBSD to XP_OPENBSD, because the former isn't defined for
preprocessor.py. (It's also only defined in C/C++ when chromium-config.h is
included, which isn't always the case.)
Differential Revision: https://phabricator.services.mozilla.com/D37815
--HG--
extra : moz-landing-system : lando
Since Bug 1531898 fix, fix of Bug 1552734 is not necessary anymore. The backout reduces memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D38257
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26412
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26411
--HG--
extra : moz-landing-system : lando
RenderTargetOGL::Bind on mWindowRenderTarget needs to bind the default framebuffer, not framebuffer 0.
Differential Revision: https://phabricator.services.mozilla.com/D26405
--HG--
extra : moz-landing-system : lando
This should ensure that the OOPIF gets painted and attached to the
compositor layer tree before the main part of the test starts. We might
be able to do something more sophisticated like waitForAllPaints or
flushApzRepaints, but it's not trivial because this page loads with an
example.com domain and can't easily access SpecialPowers.
Differential Revision: https://phabricator.services.mozilla.com/D38225
--HG--
extra : moz-landing-system : lando
When rendering text in webrender we rasterize glyphs either in local
space at a chosen raster scale, or in device space taking in to
account to text's transform.
We are not able to rasterize glyphs larger than a certain size,
however. So if the device-space font size exceeds this limit, then
currently we force the glyph to be rasterized in local space, at the
untransformed font size. This must then be scaled by the shader when
rendering text, and at high zoom levels this will result in blurry
text.
This change makes it so that rather than rasterizing at the
untransformed font size we rasterize at the font size limit. This will
mean the glyphs are rasterized at a larger size and will therefore
require less scaling, meaning they will appear less blurry.
Differential Revision: https://phabricator.services.mozilla.com/D37644
--HG--
extra : moz-landing-system : lando
This is a follow up to bug 1564655. It removes the offset from ToDeviceSpace
and thus moves item rects into absolute space which is now the same coordinate
space as the recordings are in.
We also adjust item bounds for fallback blobs.
Some additional changes that need happen to:
1. In Moz2DImageRenderer we can reunify the origin because the recording and
the recording metadata return to using the same coordinate space.
2. The calls to PushLayer can return to using the item bounds
which are now in the same coordinate space.
3. This dirty rect which remains in images space is adjusted during merging.
Differential Revision: https://phabricator.services.mozilla.com/D38015
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
