Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--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
It is theorically possible that the WinCompositorWindowThread failed to start. Should this happen, attempting to shut it down will cause shutdown to hang forever.
Differential Revision: https://phabricator.services.mozilla.com/D32602
--HG--
extra : moz-landing-system : lando
The value of the pref may change between start and shutdown.
So we shouldn't rely on that pref to determine if we need to shutdown on thread started earlier if that pref was true.
Differential Revision: https://phabricator.services.mozilla.com/D32601
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
The EGL context must be set before the call to eglSwapInterval to ensure that it will operate on the correct context.
Differential Revision: https://phabricator.services.mozilla.com/D30282
--HG--
extra : moz-landing-system : lando
Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--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
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--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
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
During the visibility pass, the main clip chain instance for each
primitive is created. In the prim prepare pass, a clip chain instance
is generated for each segment (of primitives that are segmented).
This previously required maintaining the active clip chain stack
during both passes. However, this is not ideal for a number of
reasons: the code is somewhat complicated / error prone and the
segment clip chain building step does more work than required.
This patch changes the segment clip chain building code to set up
the active clip nodes based on the result of the initial clip
chain built for the overall primitive during the visibility pass.
This means that it's no longer necessary to maintain the active
clip chain stack during the prepare pass. This simplifies some
upcoming picture caching changes related to avoiding redundant
cache invalidations, which is the main motivation for the change.
Differential Revision: https://phabricator.services.mozilla.com/D32250
--HG--
extra : moz-landing-system : lando
This is a follow-up to https://phabricator.services.mozilla.com/D30600
Previously, I changed changed the space mapper logic to use the world transformations.
This was seemingly needed because we requrested the relation between primitives and
their clip nodes, which could be in unrelated spatial sub-trees.
However, I believe the change was a mistake, since for clips we should not even try
to get the relative mapping, and clipping is done in world space for these cases.
This change reverts that logic back. ~~Fingers crossed for the try to not show any
asserts firing up inside get_relative_transform.~~ Try is green 🎉
Differential Revision: https://phabricator.services.mozilla.com/D32382
--HG--
extra : moz-landing-system : lando
These tests cause panics in debug mode because of the extra GL error
checking. Tests that are disabled are annotated with the failing
GL call.
Differential Revision: https://phabricator.services.mozilla.com/D32012
--HG--
extra : moz-landing-system : lando
This makes it so that when running reftests, wrench actually terminates
after a panic rather than just hanging. Termination is detectable and so
we can clean up properly instead of waiting until some other layer hits
a timeout.
Differential Revision: https://phabricator.services.mozilla.com/D32010
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--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
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--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
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D30213
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
This adds the base64 encoded color profile to the about:support page in
order to allow us to better diagnose and reproduce color management
issues. We can extract this, decode it and load it directly via the
gfx.color_management.display_profile pref.
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
In bug 1527182 we made it so that APZ can directly drag-scroll scrollframes
that are inside SVG effects, because that's possible with WR on the compositor.
However the code changed in that bug was meant to be kept in sync with
a second piece of code. The second piece of code controls the generation
of ScrollInfo items for scrollframes inside SVG effects - since we can
APZ-scroll them with WR, we don't need the scrollinfo item anymore.
Producing the scrollinfo item was changing the structure of the APZ tree
in terms of where the transform ended up, and was causing badness with
untransforming the drag mouse events.
This patch adds a test that covers the scenario and also corrects the defect
by bringing the two bits of code back in sync.
Differential Revision: https://phabricator.services.mozilla.com/D31647
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
Also remove extra plumbing from WebGLShaderValidator, moved directly
into WebGLShader.
Differential Revision: https://phabricator.services.mozilla.com/D31567
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
--HG--
extra : moz-landing-system : lando
This makes DrawTarget and ReadTarget no longer require a borrow
on a texture. This was previously fine, but in the near future
WR will be rendering picture caching surfaces directly into
texture handles. To allow this, we need to remove the borrow check
requirement on DrawTarget for rustc.
Differential Revision: https://phabricator.services.mozilla.com/D31390
--HG--
extra : moz-landing-system : lando
The CompositorBridgeParent won't have a LayerManager when running with
WebRender, so attempting to take a composition recording will cause a crash. We
now silently fail to take the recording since recording is not supported on Web
Render.
Differential Revision: https://phabricator.services.mozilla.com/D31169
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
This moves the existing constants into a ReftestEnvironment which
encapsulates it a bit better. Also this fixes the incorrect "debug" cfg
check to "debug_assertions" which is more correct.
Differential Revision: https://phabricator.services.mozilla.com/D31181
--HG--
extra : moz-landing-system : lando
This moves the existing constants into a ReftestEnvironment which
encapsulates it a bit better. Also this fixes the incorrect "debug" cfg
check to "debug_assertions" which is more correct.
Differential Revision: https://phabricator.services.mozilla.com/D31181
--HG--
extra : moz-landing-system : lando
ColorMatrix is rarely used but takes most space in the Filter enum.
This removes 44 bytes from the enum and all structs that embed it.
Differential Revision: https://phabricator.services.mozilla.com/D30910
--HG--
extra : moz-landing-system : lando
sed -i 's/RenderTaskTree/RenderTaskGraph/g' gfx/wr/webrender/**/*.rs
sed -i 's/task tree/task graph/g' gfx/wr/webrender/**/*.rs
Differential Revision: https://phabricator.services.mozilla.com/D30897
--HG--
extra : moz-landing-system : lando
Rename the old overlapping corners testcase and add comments to make
the tests' purposes clearer:
* The existing one is testing that a corner is clipped correctly when
it overlaps with an adjacent corner.
* The new one is testing that corners and segments are clipped
correctly when opposite edges of the border overlap.
Depends on D30814
Differential Revision: https://phabricator.services.mozilla.com/D30815
--HG--
rename : gfx/wr/wrench/reftests/border/border-overlapping-ref.yaml => gfx/wr/wrench/reftests/border/border-overlapping-corner-ref.yaml
rename : gfx/wr/wrench/reftests/border/border-overlapping.yaml => gfx/wr/wrench/reftests/border/border-overlapping-corner.yaml
extra : moz-landing-system : lando
To fix bug 1496540 it was made so that webrender clips border corner
segments so that they do not overlap with their opposing
edges. However, cases where opposing _edges_ both overlap with
eachother (rather than just a corner overlapping with an edge), the
corners are clipped too far and a gap is left in the middle.
Additionally, no clipping was added to the edge segments. So rather
than there be a gap there is an area that is painted twice, which is
apparent if the colour is semi-transparent.
This fixes these issues by identifying when opposing edges overlap and
calculating the midpoint, then clipping the edges and corners to that
midpoint instead.
Differential Revision: https://phabricator.services.mozilla.com/D30814
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
The implementation of `Device::map_pbo_for_readback` on GLES (e.g., Windows
with ANGLE) was using the incorrect enumeration value when attempting to map
the buffer into memory.
Differential Revision: https://phabricator.services.mozilla.com/D31156
--HG--
extra : moz-landing-system : lando
* Store render task address per-instance rather than per-primitive, to allow adding a single primitive to multiple batches / render tasks.
* Store render task id inside alpha batch builder, since multiple batch builders will be passed in future.
* Add primitive visibility mask, storing a bit mask of which dirty regions a visible primitive intersects.
* Store RenderTaskAddress as a u16 in CPU and shader types.
* Add picture caching debug flag to wrench.
Differential Revision: https://phabricator.services.mozilla.com/D30854
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
I think we just accidentally forgot these ids when we added more mobile
chips.
Differential Revision: https://phabricator.services.mozilla.com/D30940
--HG--
extra : moz-landing-system : lando
Many tests only had it enabled because it was required for zooming to work on
desktop. This patch revises tests to only use it if they actually use a non-
default meta viewport tag.
The motivation is to bring test coverage closer to the platform defaults (so
on desktop, tests will run with dom.meta-viewport.enabled=false, and on Android
with dom.meta-viewport.enabled=true, matching the production scenarios).
Depends on D30988
Differential Revision: https://phabricator.services.mozilla.com/D30989
--HG--
extra : moz-landing-system : lando
When the clip chain generates the local clip rect for a primitive, it
can be empty. This violated the assumption that the visible rect will
never be empty, and so when we snap, it produces NaNs, which in turn,
violates other assumptions when converting between spaces, and hence the
crash.
Now we cull the primitive from the visible list if the local clip rect
is empty, or if the visible rect is empty.
Differential Revision: https://phabricator.services.mozilla.com/D30659
In some cases, Gecko supplies a display item with an image clip
mask where the image itself does not exist in the resource cache.
In these cases, WR would skip requesting the image, but would
still try to fetch the image info during batching, causing a panic.
This patch skips adding clip items to the batching pass if the
image mask does not exist.
It also adds support to wrench for a crash test when the image
mask is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D30560
--HG--
extra : moz-landing-system : lando
This change makes get_relative_transform() to no longer rely on any flattening done before in the pipeline.
This makes it correct is some of the cases we failed previously (see ini files removed).
It now does flattening on every flat coordinate system it passes through, and it's used for SpaceMapper.
The old RelativeTransform is now replaced with CoordinateSpaceMapping, which reduces the zoo of our types :)
Differential Revision: https://phabricator.services.mozilla.com/D30600
--HG--
extra : moz-landing-system : lando
This patch is scaffolding only - there shouldn't be any functional
changes as a result of these changes.
Differential Revision: https://phabricator.services.mozilla.com/D30330
--HG--
extra : moz-landing-system : lando
This moves creation of the render task graph to be slightly
earlier during frame building. Instead of creeating the render
tasks during prepare_prims, they are created during the
take_context call for pictures, before recursing into primitives.
This means that in future we can have a surface that targets
multiple render tasks (e.g. for multiple dirty regions), which
may create a different batch set for each region.
Differential Revision: https://phabricator.services.mozilla.com/D29994
--HG--
extra : moz-landing-system : lando
cargo fix works by building under a specific config, so we can't hit both
sides of a mutually exclusive pair of cfgs, such as cfg(target_os) or
when cfg(feature) and cfg(not(feature)) both exist in the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D29568
--HG--
extra : moz-landing-system : lando
Notably `extern crate foo as bar` is no longer supported
(must do it in Cargo.toml). Also stopped using euclid through webrender_api,
because it produces worse results in 2018.
Differential Revision: https://phabricator.services.mozilla.com/D29566
--HG--
extra : moz-landing-system : lando
There's two ways we could get around this. We could add a path
around the prepared_for_frames assertion in GpuCache::end_frame,
or we can do this, and leave the TODO explicit with the
assertion. I took the latter approach because we can clear
the GpuCache / TextureCache through other routes than frame
building anyway, so we could hit this failure path before
any of the patches in this bug landed.
Differential Revision: https://phabricator.services.mozilla.com/D29884
--HG--
extra : moz-landing-system : lando
These aren't great names - I couldn't come up with better though.
We lose the symmetry of before/after but this clarifies a little
bit what they are doing.
Differential Revision: https://phabricator.services.mozilla.com/D29877
--HG--
extra : moz-landing-system : lando
If we run a GpuCache clear and do not update all documents, we run into
situations where the stale documents try to access things in the gpu
cache and just show random garbage. The solution is similar to what we
do for TextureCache, so I am just duplicating those signatures and providing
helpers in RenderBackend to access both together.
Differential Revision: https://phabricator.services.mozilla.com/D29860
--HG--
extra : moz-landing-system : lando
Currently it's possible for the RemoteContentController in the GPU process to
be sending a message to the UI process while the UI process is running
RemoteCompositorSession::Shutdown. This means that by the time that message
is processed, the UI process actor is destroyed and the message produces
a routing error.
This patch ensures that before RemoteCompositorSession::Shutdown completes,
it notifies the RemoteContentController in the GPU process that it's about
to destroy the APZChild actor. This eliminates the race because it ensures
the RemoteContentController is synchronously notified of the impending
actor destruction before it tries to send the message.
Differential Revision: https://phabricator.services.mozilla.com/D29941
--HG--
extra : moz-landing-system : lando
Due to the render task ping-pong target allocation scheme, we need to ensure:
- that tasks only read from tasks that are an odd number of passes apart,
- that render task content is kept valid long enough for all of the dependent tasks.
The former is solved in this patch through blit tasks, the latter by marking tasks for saving as needed.
Differential Revision: https://phabricator.services.mozilla.com/D29800
--HG--
extra : moz-landing-system : lando
Typically this would be handled by the visible region of the layer
changing. However, since we build the container layer for the filter
item directly the visible region doesn't get set or checked. As a
shortcut to using more of FLB we just ensure the building rect hasn't
changed.
The situations under which this bugs shows up are somewhat rare:
- The filtered item needs to be in transform so that it's bounds
are not changed by scrolling.
- The filtered item needs to contain items that change their drawing
depending on the building rect. In this case an image with downscale
on decode.
- The filter needs to be unsupported by WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D29879
--HG--
extra : moz-landing-system : lando
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
If a document has an empty rect for whatever reason (in the case observed, this was
due to running a full screen video in the content document, which occludes the
chrome document), then we still want to ensure that we build a frame if the
texture cache has performed a clear, as otherwise we may try to access stale
items from the texture resolver in render_impl.
Differential Revision: https://phabricator.services.mozilla.com/D29848
--HG--
extra : moz-landing-system : lando
