* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Maintain a running total of bytes allocated in both standalone and
shared cache regions. This is used as a threshold to know when to
force a mid-frame eviction. Previously, as soon as the currently
allocated set of shared textures were full, we'd force an eviction.
This means that in typical use cases, we were forcing an eviction
as soon as the texture cache is > 16 MB, which is inefficient.
* Separate out picture cache eviction from the normal cache eviction
path. This will be important in the next patch which will change
the eviction algorithm for all shared / standalone entries.
* Remove Eviction::Eager as a policy option for shared and standalone
textures. As part of this, switch render task cache entries to use
Eviction::Auto. This is a better option anyway, there is no real
benefit to evicting render tasks as soon as possible - they should
be expired based on usage, just as for normal cache entries.
Differential Revision: https://phabricator.services.mozilla.com/D77983
Do full render with WebRender when Dwn is disabled. It could be done by RenderCompositorANGLE::RequestFullRender().
Back out Bug 1638469. It disables WebRender during starting if Dwm is disabled. But Dwm is enabled/disabled dynamically. And we do not want to disable WebRender in this case.
Differential Revision: https://phabricator.services.mozilla.com/D77221
Some pages created nesting levels of scroll roots where the outer
scroll frames are redundant (the scrollable size is zero if the
content rect is the same as the frame rect).
In these cases, it is of no benefit to select these as a scroll
root for picture cache tiles.
Differential Revision: https://phabricator.services.mozilla.com/D75451
If not, vsync keeps going and can get called after the main thread has gone away, and in VsyncSource::Display::NotifyVsync (with the patches for bug 1630912) we try to dispatch to the main thread which fails and asserts.
Differential Revision: https://phabricator.services.mozilla.com/D74017
We have encountered issues when rolling out WebRender because the
configuration logic is quite complicated. It would serve us well to have
it in a form that we can easily test. This patch does said refactor, as
well as adds an initial set of tests.
Differential Revision: https://phabricator.services.mozilla.com/D72027
UnpremultiplyRow will be used in the image encoders to reverse
premultiplication. SwizzleRow needs to support copying (no swizzling)
and swapping RGB/BGR.
Differential Revision: https://phabricator.services.mozilla.com/D66743
--HG--
extra : moz-landing-system : lando
The test added in this changeset is already fixed by the no-normalization change, but there are probably cases that require the explicit check that this patch adds.
When we were still normalizing the plane normals, the TransformAndClipBounds call in the added test was returning (1023.999878, 1023.999878, 0.000061, 0.000122).
Depends on D68703
Differential Revision: https://phabricator.services.mozilla.com/D68704
--HG--
extra : moz-landing-system : lando
For example, if the clipping rectangle has aClip.X() == 1024, then the normal for the clipping plane induced by the left edge of the clip will now be (1, 0, 0, -1024) rather than (0.0009765620343390458, 0, 0, -0.9999995231631829).
This change is mathematically valid:
- The dot products computed from these vectors become multiplied by planeNormal.Length() (compared to before this patch).
- The sign of the dot products is not affected, so the "intersection with plane" check is not affected:
`if ((nextDot >= 0.0) != (prevDot >= 0.0)) {`
- The value of the dot products is only used to compute `t`, as follows:
`F t = -prevDot / (nextDot - prevDot);`
Here, the length now appears both in the numerator and in the denominator, canceling itself out.
As a result from this change, the existing tests no longer require integer nudging in order to pass.
Depends on D68702
Differential Revision: https://phabricator.services.mozilla.com/D68703
--HG--
extra : moz-landing-system : lando
UnpremultiplyRow will be used in the image encoders to reverse
premultiplication. SwizzleRow needs to support copying (no swizzling)
and swapping RGB/BGR.
Differential Revision: https://phabricator.services.mozilla.com/D66743
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This fixes a bug that was introduced three years ago in bug 1268854.
What happened was that the final pass over the polygon assumed that the current
polygon was living in plane[0]. But due to the double buffering, the "current"
polygon alternates between plane[0] and plane[1]. And bug 1268854 had introduced
an early exit so that we could hit the final pass at a time where the current,
now empty, polygon was in plane[1]. So we would incorrectly treat all 32 points
in plane[0] as part of the final polygon.
This bug was responsible for intermittently unreasonable numbers in CompositorOGL's fill
rate / overdraw overlay, and, since changeset cc84a0e9d5ddde198422f4f11ab6bf85f631d5f0,
also caused CompositorOGL to execute unnecessary draw calls.
Differential Revision: https://phabricator.services.mozilla.com/D44312
--HG--
extra : moz-landing-system : lando
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Changes:
- added comments for tests being disabled
- disabled two additional tests in order to green the run
Differential Revision: https://phabricator.services.mozilla.com/D28085
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
Several tests in marionette are failing in `Mn`, `MnH`, `MG` for windows10-aarch64.
This patch disables the tests that are failing.
Individual issues are recorded in:
- 1536278
- 1536369
Differential Revision: https://phabricator.services.mozilla.com/D23991
--HG--
extra : moz-landing-system : lando
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/composite/ContainerLayerComposite.cpp:132:6 [-Wmissing-prototypes] no previous prototype for function 'TransformLayerGeometry'
gfx/layers/composite/LayerManagerComposite.cpp:1409:6 [-Wmissing-prototypes] no previous prototype for function 'ComputeVisibleRegionForChildren'
gfx/layers/composite/LayerManagerComposite.cpp:234:6 [-Wmissing-prototypes] no previous prototype for function 'ShouldProcessLayer'
gfx/layers/composite/TiledContentHost.cpp:156:6 [-Wmissing-prototypes] no previous prototype for function 'UseTileTexture'
gfx/layers/ipc/CompositorBridgeParent.cpp:1827:6 [-Wmissing-prototypes] no previous prototype for function 'EraseLayerState'
gfx/layers/ipc/CompositorBridgeParent.cpp:2140:6 [-Wmissing-prototypes] no previous prototype for function 'UpdateIndirectTree'
gfx/layers/opengl/OGLShaderProgram.cpp:28:6 [-Wmissing-prototypes] no previous prototype for function 'AddUniforms'
Differential Revision: https://phabricator.services.mozilla.com/D20265
--HG--
extra : source : f5653a8b1bc5a02cf899fe87cb3ebc9796b0b0b1
extra : histedit_source : 4f44f15098c42b4b1fa141de7b8593c128b58596
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/Layers.cpp:58:7 [-Wmissing-prototypes] no previous prototype for function 'FILEOrDefault'
gfx/layers/ipc/CompositorThread.cpp:26:25 [-Wmissing-prototypes] no previous prototype for function 'GetCompositorThreadHolder'
MINIMUM_TILE_COPY_AREA()
Differential Revision: https://phabricator.services.mozilla.com/D20266
--HG--
extra : rebase_source : 5c80a140cbd661644e2076a8852a0cfe58539083
extra : source : 7f44c2bcebce0b4bd549d653e4eff8b4bad71e29
The Google weather search result widget has an SVG inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that the SVG elements would not get clipped by the scrollframe. This
reftest exercises that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18273
WhatsApp Web has emojis in divs with border-radius, inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that scrolling the scrollframe would make the emoji visible outside the
scrollframe. This reftest replicates that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18272
The Google weather search result widget has an SVG inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that the SVG elements would not get clipped by the scrollframe. This
reftest exercises that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18273
WhatsApp Web has emojis in divs with border-radius, inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that scrolling the scrollframe would make the emoji visible outside the
scrollframe. This reftest replicates that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18272
It turns out that setting the parent link on a clip chain is no longer
needed (and probably hasn't been since WR started applying a stacking
context's clip to the SC's contents). In fact it can produce incorrect
behaviour in some cases, because it doesn't match the semantics of
Gecko's clip chains. This removes the parent link on the Gecko side and
adds a test for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18101
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
In nsDisplayTransform::CreateWebRenderCommands we should be rounding the
translation from the reference frame if there is no other transformation
to better match non-WebRender which performs similar rounding in
ChooseScaleAndSetTransform.
Differential Revision: https://phabricator.services.mozilla.com/D14265
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
re-open of D16335, which got backed out due to Wrench test failing.
The test was failing because of different AA on a plane-splitting case, which isn't guaranteed anyway.
This revision updates the test.
Differential Revision: https://phabricator.services.mozilla.com/D16560
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
In order to reduce the cost of running marionette tests on a virtual machine
with a GPU, add a marionette-gpu job, and run the WebRender rollout test added
in the previous patch in this new job.
Depends on D10528
Differential Revision: https://phabricator.services.mozilla.com/D12241
--HG--
extra : moz-landing-system : lando
Add test that when we restart the browser with a default value set on
gfx.webrender.all.qualified, Firefox saves that value and checks respects
the saved value when initializing WebRender.
Depends on D10527
Differential Revision: https://phabricator.services.mozilla.com/D10528
--HG--
extra : moz-landing-system : lando