Newer Android supports multiple refresh rate that is dynamically changed.
Actually, GeckoView will always pass the refresh rate value to vsync when
getting it first time.
So this fix changes that GeckoView gets the refresh rate when vsync is started.
Differential Revision: https://phabricator.services.mozilla.com/D168665
These crashtests rely upon either a requestAnimationFrame callback or a
MozAfterPaint event. Those currently won't happen when the compositor is
paused, and on Windows these crashtests are occluded, which will now pause
the compositor. To deal with this, we disable the occlusion tracking pref
on Windows. Other platforms seem not to treat the crashtests as occluded,
so their compositors keep running.
Differential Revision: https://phabricator.services.mozilla.com/D171137
The main goal of this is to fix an implementation detail where the
WR code had to read every primitive in the tile even when checking
if a small sub-tile was valid (as the advance amounts of the
primitive dependency array vectors was stored in each primitive).
However, this patch itself is quite a significant optimization, it
improves displaylist_mutate by ~16%.
Instead of maintaining separate arrays for each dependency, use
a single byte array and use peek-poke to store these dependencies.
This simplifies the code for comparing dependencies, and makes the
traversal of sparse index buffers of the primitive array much faster.
Differential Revision: https://phabricator.services.mozilla.com/D170710
Also update some FOG tests that are now incorrect (label limits have been
lifted).
The `default_features = false` on `env_logger` are to avoid a new, duplicate
dependency on hermit-abi.
Differential Revision: https://phabricator.services.mozilla.com/D170816
During font-list initialization, we call Core Text to "activate" the supplemental language fonts,
and potentially any bundled fonts shipped with the app. But this generates an OS notification,
which if we process it will cause a redundant rebuild of our list. So to avoid this, set a flag
when we activate the fonts, telling us that the upcoming notification can be ignored.
Differential Revision: https://phabricator.services.mozilla.com/D171205
Running WebGL on the Renderer thread is causing inexplicable browsertime harness failures. Since there is
still contention with the main thread, moving WebGL work from the CanvasRenderer thread to the Renderer
thread probably has only a small impact on the incidence of bug 1777849.
However, there were other stack size issues fixed there, so we want to leave the stack size fixes in
place.
Differential Revision: https://phabricator.services.mozilla.com/D171147
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
Right now we add global reference to DMABufSurface in VideoFrameSurface when it's allocated by decoder and release it when DMABUFSurfaceImage deleted by MediaSupervisor.
It's not very obvious so in this patch we move DMABufSurface references to DMABUFSurfaceImage only, we add global ref when DMABufSurface is put to DMABUFSurfaceImage
and unref when DMABUFSurfaceImage is deleted.
Differential Revision: https://phabricator.services.mozilla.com/D170625
There were cases that mVideoSwapChain->Present() took long time. It caused low fps and stuttering and lots of dropped frames. When it happens, disabling video overlay could address the problem.
Differential Revision: https://phabricator.services.mozilla.com/D171039
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
It shouldn't be necessary to do this at startup, only on first use of LookupLocalFont.
(We can also simplify things a bit: now that we don't support pre-10.6 systems where
the symbol wasn't present, we don't need to do a runtime dlsym() check.)
Differential Revision: https://phabricator.services.mozilla.com/D170998
In `gfx/config/gfxFeature.{h,cpp}`, it can be observed that a `mozilla::gfx::FeatureState` is
a state machine that collects different "levels" of enabled-ness. To summarize[^1], these are:
1. Default
2. User
3. Environment
4. Runtime
The rules for initializing each of these layers are basically that:
1. At least (1) must be initialized, otherwise, the feature is "unused".
2. Other levels may only be initialized (or re-initialized) if (a) all previous levels were
initialized, and (b) no subsequent levels are initialized. Otherwise, throw an assertion
error.
In the bug we're fixing here, we were attempting to configure the environment level before the user
level, which violates rule 2. Oops! Make sure we init the user level before initting the
environment level.
[^1]: You can find a better description of the intent of each layer at <https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/gfx/config/gfxFeature.h#147-155>.
Differential Revision: https://phabricator.services.mozilla.com/D170764
- Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
- Request full screen update when widget size changes on Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D169905
To run webrender's wrench tests the app needs to read a file to parse
the command line args from, and write a file with the test
output. These files also need to be written and read manually over adb
by the engineer running the tests (or more likely by the
android_wrench.py script).
Currently we use the external data dir for these files. However, on
recent android versions these are no longer accessible to the app
without jumping through some hoops. This patch makes us instead use
the internal data dir. It also makes the app "debuggable" so that
these files can be written to via adb using run-as.
Additionally, we must ensure that the android_wrench.py script uses
run-as instead of root to push and pull the files, as root does not
have permission to do so on recent android versions.
Differential Revision: https://phabricator.services.mozilla.com/D169829
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
- Create wheel transactions for wheel events handled by APZ.
- Group wheel events with the current wheel transaction, so that all
wheel events in a wheel transaction are fired to the same element.
- Store the current event target for the first event in a wheel
transaction to be used for subsequent events.
- Add the dom.event.wheel-event-groups.enabled preference as a feature
flag for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D163484
Simplifies some upcoming work to change how we store these when
updating primitive dependencies during picture cache updates.
Differential Revision: https://phabricator.services.mozilla.com/D170546
It is unclear that we want it enabled for all users and this way we don't have to audit the changes in renderdoc-sys.
We can and should revisit this in the future if we feel like it would be useful to ship with webgpu+renderdoc integration.
Differential Revision: https://phabricator.services.mozilla.com/D170492
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
This patch adds two new prefs, gfx.webrender.scissored-cache-clears
.enabled and .force-enabled to control its status beyond the blocklist.
The former is true by default and allows one to turn the feature off by
flipping it to false. The latter allows one to force the feature on even
if the blocklist disables it. It also adds the status to the decision
log in about:support.
Differential Revision: https://phabricator.services.mozilla.com/D170507
This change makes the VIDEO_LOG only output the first surface sent to a
video layer (whether an AVSampleBufferDisplayLayer or a CALayer), and
notes whenever the video layer has been recreated. This will be helpful in
diagnosing cases degenerate cases where display of video content toggles
between a specialized video layer and a normal layer.
Differential Revision: https://phabricator.services.mozilla.com/D170154
- Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
- Request full screen update when widget size changes on Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D169905
This patch exposes an unrelated issue that causes a performance regression.
For now, we'll revert this to get back to a normal baseline. Then, separately
fix the underlying code which regresses perf, then re-land this patch.
Revert "Bug 1811978 - Enable the new tiled rendering path, update test expectations r=gfx-reviewers,nical"
This reverts commit 7f3a2568aabf9fa2358fe0f7421042ba85a23442.
Differential Revision: https://phabricator.services.mozilla.com/D170399
This replaces CTFontManagerRegisterFontsForURLs, which is deprecated since macOS 10.15.
(No user-visible behavior change.)
Depends on D170287
Differential Revision: https://phabricator.services.mozilla.com/D170288
No user-visible behavior change; just trying to move a bit more work onto a secondary thread,
in the hope of improving startup perf (althogh if there's too much contention for disk i/o,
or not enough CPU cores available, it may not help much).
Depends on D170286
Differential Revision: https://phabricator.services.mozilla.com/D170287
Local testing indicates that if we don't do this, there's a risk that Core Text will resolve font names
differently in the content vs parent processes when duplicate fonts are installed (e.g. old versions of
Arial, Helvetica, etc that some users have "inherited" from ancient systems). The mismatched fonts used
for layout (in the content process) vs painting (by the parent) lead to the "garbled text" issue.
Unfortunately, this will impact content-process startup on macOS, so expect a perf regression report.
In my local testing, this appears to prevent the "garbled text" problem when an old version of Arial is
installed, or other similar font mismatch situations. There should be no user-visible behavior change
for systems with a "clean" font installation.
Differential Revision: https://phabricator.services.mozilla.com/D170286
This change computes the new invalid region of the in progress surface
during the partial update, and asserts that the update region is
sufficient to cover it. This will assert earlier than the asserts in
NotifySurfaceReady, under similar conditions. Hopefully this will help us
identify if we are using an incorrectly calculated update area.
Additionally, it reorganizes the region boolean logic in
NativeLayerCA::HandlePartialUpdate to avoid adding in the update region
just to subtract it away again.
It also confirms that callers to the layer are always either using the
drawn surface call (NotifySurfaceReady) or the external surface call
(AttachExternalImage).
Differential Revision: https://phabricator.services.mozilla.com/D169019
Forcing specialized video in this case was overriding the user's ability
to opt-out by setting the pref, while providing no benefit. Adding the
macOS version check around this makes our logic here consistent with our
setting of preventsCapture in ApplyChanges.
Differential Revision: https://phabricator.services.mozilla.com/D169849
This reverts the per-glyph-run optimization landed in bug 1816299, and replaces it with a per-glyph version
that will work within a long run of glyphs in a single font, as well as across the glyph runs in a mixed-font textrun.
To minimize the cost of the check, rather than retrieving individual glyph bounds, we use the overall font extents.
(Note that this uses the bounding box min/max coordinates from the 'head' table, which may exceed the typographic
ascent/descent of the font, and the advances of the glyphs; we care about the ink extents, not typographic size.)
Differential Revision: https://phabricator.services.mozilla.com/D170058
This seems tricky to test in CI as it doesn't reproduce consistently
(originally reported on Windows, but I haven't been able to reproduce it
there at all; but successfully repro'd and tested locally on Linux).
Differential Revision: https://phabricator.services.mozilla.com/D169935
This is an unsavoury workaround to let the fuzzing team make progress while we are sorting through our blob layerization and sizing issues.
This adds a hidden pref "gfx.webrender.debug.restrict-blob-size", which, when set to true, clamps the size of blob images to 2048x2048.
This means that bigger blobs will render incorrectly but will be less likely to cause OOMs.
Differential Revision: https://phabricator.services.mozilla.com/D169944
This substantially improves performance when there are lots of
individual emoji glyphs scattered through a textrun, each resulting
in a separate glyphrun using the emoji font.
Differential Revision: https://phabricator.services.mozilla.com/D169926
A consequence of the previous patch in this series, which allows
partial picture cache tile invalidation on recent Mali GPUs, is that
we will start using a scissored clear to clear the tile if the dirty
region is smaller than the entire tile. We saw in bug 1809738 that a
scissored clear can be less efficient.
If it allows us to re-render less of the tile that is probably a
worthwhile trade off. However, we frequently encounter a case where
the entire valid_rect of a tile is dirty, but that is smaller than the
entire texture. This is because our tiles are 1024x512 pixels, so for
example on a 1080 pixel wide screen, the 2nd column of tiles will only
have a valid_rect that is 56 pixels wide. In such cases, using a
scissored clear does not reduce the amount of rendering required.
This patch therefore makes it so that we use an unscissored clear (on
devices where that is preferrable) if the dirty_rect is equal to the
valid_rect.
Depends on D169890
Differential Revision: https://phabricator.services.mozilla.com/D169891
We previously blocked partial picture cache tile invalidation on
Mali-T and Mali-G devices due to several bugs. These issues no longer
appear to reproduce on recent Mali GPUs: eg G77, G78, G710 which are
all "Valhall" architecture. This patch therefore keeps the workaround
for all Midgard and Bifrost GPUs, but removes it for others.
Differential Revision: https://phabricator.services.mozilla.com/D169890
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
Now Windows and Linux/wayland can return screen orientation type/angle,
so we should get it from current screen instead of primary screen.
Differential Revision: https://phabricator.services.mozilla.com/D169414
about:support's feature table still shows blocklisting, just not whether
the pref is set.
If different from default, dom.webgpu.enabled still shows up in about:support under
"Important Modified Prefs" like normal.
Also renames "gfx.webgpu.force-enabled" to "gfx.webgpu.ignore-blocklist"
to reflect its functionality.
Differential Revision: https://phabricator.services.mozilla.com/D169007
If the glslopt pass fails to optimize a shader, we helpfully print the
shader source so that it is easy to find what the problem is. However,
we print this from within the build_parallel call, meaning if multiple
shaders fail to optimize we print all of their sources and they get
interleaved with each other, making it very difficult to find the
problematic line.
This patch makes us delay printing the source until the same place
where we print the error log, after we have stopped processing in
parallel. This means we will only print the source of a single
shader (the first one which fails to optimize), along with the error
log for that shader, which is much easier to debug.
This also includes a small tidy-up to handle both vertex and fragment
shaders in a loop to remove code duplication, and runs rustfmt.
Differential Revision: https://phabricator.services.mozilla.com/D169618
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
This is actually a bug that pre-dates the regression here, but I haven't seen a report
of it or a specific test failure that results. However, the new WPT reftests I'm
intending to land for the slant issue do exhibit a failure until this is fixed,
so let's go ahead and do it here.
Differential Revision: https://phabricator.services.mozilla.com/D169334
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
In bug 1809738 we found that our scissored render target clear
optimization actively hurt performance on some Mali GPUs. From testing
on a variety of Android devices, we have found that it mostly makes no
difference either way, but hurts performance on some other GPUs
too. On software webrender, however, it is still a performance win.
This patch therefore disables the optimization on all Android, apart
from when using software webrender.
Differential Revision: https://phabricator.services.mozilla.com/D169062
GCC 13s libstdc++ reduced its dependency on some headers like <cstdint>,
so it's no longer transitively included through various headers.
Include it explicitly.
See also: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
11:16.32 .../components/telemetry/pingsender/pingsender.cpp:30:7:
error: unknown type name 'uint32_t'
11:16.33 const uint32_t kConnectionTimeoutMs = 30 * 1000;
11:16.33 ^
11:16.33 ... /components/telemetry/pingsender/pingsender.cpp:76:9:
error: unknown type name 'uint32_t'
11:16.33 const uint32_t kBufferSize = 4 * 1024 - 1;
11:16.34 ^
11:16.44 2 errors generated.
(et al)
Differential Revision: https://phabricator.services.mozilla.com/D167491
Similar to the other GetCurrentAsync*() functions,
GetCurrentAsyncVisualViewport() takes into account the async test
attributes as well as the frame delay.
It supersedes GetCurrentAsyncScrollOffsetInCSSPixels() which can
be obtained as the the TopLeft() of the visual viewport rect.
Differential Revision: https://phabricator.services.mozilla.com/D163148
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
This enables my local build to achieve 60fps on the js1k demo linked from the bug,
whereas without the patch I get barely 10fps.
Note: it's still possible for ComputePointAtLength would perform poorly if
the caller is iterating backwards or doing random access to a long path.
A potential mitigation for that would be to add an mLength field to FlatPathOp,
storing the length-so-far of the path, so that ComputePointAtLength could do
a binary search instead of linear accumulation. But this would add significant
memory overhead, and may not be worth doing; the low-overhead cursor here
appears to be enough to make text-on-a-path perform much better.
Differential Revision: https://phabricator.services.mozilla.com/D168937
Turns out we already had code for this in NumericTools.h, so reuse it.
I thought I was going to need this code somewhere else though I didn't
end up needing it.
While at it clean up unnecessary template params I noticed.
Differential Revision: https://phabricator.services.mozilla.com/D168460
Implementation is borrowed from RenderAndroidSurfaceTextureHost. Since Android SurfaceTexture and AndroidHardwareBuffer use same android GraphicBuffer.
Differential Revision: https://phabricator.services.mozilla.com/D168764
Currently, the rounded rect shader uses the linear distance from the corner's origin
(the ellipse origin) to select which corner to evaluate ellipse distance within. However,
this metric may fail when it believes we are currently inside multiple corners, and may
select the wrong minimal distance and thus the wrong corner. Ideally, we need to actually
compute the ellipse distance for each corner and select the minimal one, but this is
prohibitively expensive.
Instead, we use the same strategy as the SWGL span shader which is to define a half-space
plane that spans the diagonal of each corner, by which we decide if we are inside a given
corner by seeing which side of the coner diagonal's half-space plane we're on. This yields
code that is about as fast as the currently broken linear distance comparison and more
closely matches the results of the SWGL span shader as a bonus.
This also cleans up the half-space varyings to be specified in a more common plane form
of normal and offset which takes up less space while being a bit cheaper to evaluate.
Differential Revision: https://phabricator.services.mozilla.com/D168769
EffectNV12 is not used by RenderCompositorOGLSWGL/RenderCompositorLayersSWGL. EffectRGB is used by RenderCompositorLayersSWGL.
Differential Revision: https://phabricator.services.mozilla.com/D168771
This patch reverts our behaviour closer to how we worked prior to bug
1780193. Parts of bug 1780193 remain because they are necessary to
ensure there are no race conditions when interacting with the cache from
multiple threads.
Now we remove fonts from the expiration tracker when there are strong
references remaining to the object. When the last strong reference is
cleared, we readd the font to the expiration tracker. A lookup will
remove it from the tracker (and creates a strong reference). If it
expires from the tracker, it is then destroy. There are several race
conditions we need to manage because the refcount can be updated without
holding the gfxFontCache mutex.
Differential Revision: https://phabricator.services.mozilla.com/D156716
2 problems existed.
- [1] RenderAndroidSurfaceTextureHost::GetUvCoords() was not called when RenderAndroidSurfaceTextureHost is wrapped by RenderTextureHostWrapper.
- [2] NeedsYFlip() of SurfaceTextureHost::CreateRenderTexture() uses TextureHost::mFlags. But TextureHost::mFlags was updated by RemoteTextureHostWrapper::ApplyTextureFlagsToRemoteTexture() after SurfaceTextureHost::CreateRenderTexture() call. Then RenderAndroidSurfaceTextureHost::mOriginPos became wrong.
[1] is addressed by adding RenderTextureHostWrapper::GetUvCoords()
[2] is addressed by removing RenderAndroidSurfaceTextureHost::mOriginPos. It is not necessary since Bug 1731980.
Differential Revision: https://phabricator.services.mozilla.com/D168763
Disable external compositing if ImageRendering is not ImageRendering::Auto for now. It seems that we could not handle ImageRendering::Pixelated for video overlay on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D168514
Makoto Kato
Hiroyuki Ikezoe
Marian-Vasile Laza
Glenn Watson
Brad Werth
Daniel Holbert
Chris H-C
Sandor Molnar
Jonathan Kew
Jed Davis
Lee Salzman
Csoregi Natalia
Dan Robertson
Stanca Serban
stransky
sotaro
Timothy Nikkel
Erich Gubler
Jamie Nicol
Iulian Moraru
Dan Robertson
Butkovits Atila
Nicolas Silva
Andrew Osmond
Tom Schuster
Emilio Cobos Álvarez
Joel Maher
Christian Holler
Robert Longson
Fabrice Desré
Otto Länd
Kelsey Gilbert
Gijs Kruitbosch
Alex Jakobi
Andi-Bogdan Postelnicu
Cristina Horotan
Ray Kraesig
Ashley Hale
Cristian Tuns
Razvan Cojocaru
Arsen Arsenović
Botond Ballo
Norisz Fay
Nika Layzell