Provide an explicit copy constructor for the GCC `VectorType` polyfill. Since
`VectorType` has an assignment operator, GCC is uncomfortable faking a copy
constructor, so we have to provide one.
Make `VectorType` default constructor actually initialize the elements. When we
have a GLSL `if` whose condition varies from fragment to fragment, and whose
alternatives either assign to a variable or discard the fragment, we compile the
assignment to an `if_then_else` call that preserves the old elements for
fragments not taking the assignment's path. But if this is the initializing
assignment, the 'old value' operand to that `if_then_else` is uninitialized. We
could make the translator smarter about this, and have it not use predicated
assignment in such cases, but this fix is fine for now.
Make `VectorType::wrap` take its argument by const reference, to avoid weird ABI
'notes'.
Differential Revision: https://phabricator.services.mozilla.com/D71444
When the `software` feature is enabled, a clause gets added to two `match`
statements, causing Rust to complain that another `match` clause is unreachable.
This patch makes the other match clause conditional on the absence of the
`software` feature.
Differential Revision: https://phabricator.services.mozilla.com/D71443
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
Bug 1630629 moved the check UseWebRenderDCompWin before it had been
initialized. This moves it below so that DirectComposition isn't
disabled everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D71498
This provides an implementation of linear filtering via the linear_blit
routine. That required factoring out textureLinear helper functions and
reusing them to do the actual filtering of the source texture.
Some collateral cleanups involved changing IntRect to use a start/end
format instead of origin/size, cleaner ways of getting offset texture
sampler pointers, and fixing clamping of linear filter coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D70968
The FrameTexturesUpdated event is intended to be issued when any
necessary texture cache updates have been completed for the current
frame. Originally we would simply check if the pending_texture_updates
vector in Renderer is empty. However the updates themselves could be
nops, and not trigger a timely frame render to occur, causing the
notifications to be delayed indefinitely. Now we track if there are
actually any pending specifically texture cache updates and only defer
the notification if true.
A consequence of deferring the notification indefinitely was revealed
when animating images just outside the current view. We would not
release the buffers for recycling even though we had no reason to hold
onto them. This could cause the image decoder to allocate new buffers
while the old buffers would not get released. It was not a true memory
leak because as soon as a frame is rendered, it would release all of the
old buffers, but it could easily cause a out of memory crash to occur if
the user was not interacting with the browser while in this state.
Differential Revision: https://phabricator.services.mozilla.com/D70770
This moves the DirectComposition configuration code before
the WebRender configuration code so that we can depend
on the results to decide whether to user WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D71213
TaskQueues hold onto their nsIEventTarget (in this case mCanvasWorkers) until
after they resolve their shutdown promise, which is what causes
CanvasThreadHolder::StaticRelease to be submitted to the compositor thread.
So this assertion can't be guaranteed.
Differential Revision: https://phabricator.services.mozilla.com/D71176
The recording by CanvasDrawEventRecorder into the ring buffer is not thread-safe
and so must all occur on the same (main) thread.
In addition to that it sometimes needs to send IPC messages via the PCanvas
protocol, which also can only be done on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D71174
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
This patch fixes two opacity/mask optimizations when WebRender is in use:
- The first optimization defers opacity handling and applies it during painting of nsDisplayMasksAndClipPaths if it is the only item inside nsDisplayOpacity. This was broken because WebRenderCommandBuilder did not invalidate the mask image when this decision changed.
- The second optimization applies opacity directly to stacking context in |nsDisplayMasksAndClipPaths::CreateWebRenderCommands()| with non-polygonal clip-paths. This was relying on the above optimization incorrectly triggering, which flattened away the opacity container. However, if the nsDisplayOpacity was active or contained more than one item, the opacity could be applied twice.
Differential Revision: https://phabricator.services.mozilla.com/D68995
As described in bug 1630274, this has some unfixed cases, but it should
give good results in most real-world cases, where the magnitude of transient
async scrolling is relatively low.
Depends on D71083
Differential Revision: https://phabricator.services.mozilla.com/D71084
--HG--
extra : moz-landing-system : lando
This is just plumbing, no functional change. The current usage of eBottom is
parameterized and the eBottom hard-coded value is pushed out to the callers.
Depends on D70912
Differential Revision: https://phabricator.services.mozilla.com/D71083
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
The semantics of sticky items are somewhat different from the semantics of
fixed items. For fixed items, if an item is fixed to eTop or eBottom or
eTopBottom, it is *always* fixed to those sides. For sticky items, however,
the sides actively stuck to are dependent on the scroll position. So we need
a mechanism to dynamically figure out which sides are stuck, and use those
sides when computing the fixed margins to apply. This patch implements that
by modifying the IsStuckToRootContentAtBottom method into a
SidesStuckToRootContent method.
Differential Revision: https://phabricator.services.mozilla.com/D70910
--HG--
extra : moz-landing-system : lando
I couldn't understand what it was doing before, but conceptually it should
be pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D70909
--HG--
extra : moz-landing-system : lando
This sets us up to be able to use these helper methods on WR sampling codepath.
Depends on D70907
Differential Revision: https://phabricator.services.mozilla.com/D70908
--HG--
extra : moz-landing-system : lando
This will make future patches simpler, as we can now create these info objects
more easily for the non-WR codepath as well.
Depends on D70906
Differential Revision: https://phabricator.services.mozilla.com/D70907
--HG--
extra : moz-landing-system : lando
We can use the map lock to do a lookup in mApzcMap, instead of requiring the
tree lock to call GetTargetAPZC.
Differential Revision: https://phabricator.services.mozilla.com/D70906
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
This is in anticipation of having a looser condition for enabling
DComp. Until that code is ready we might as well get more testing.
Differential Revision: https://phabricator.services.mozilla.com/D71060
--HG--
extra : moz-landing-system : lando
CanvasClientSharedSurface did not handle a case that CanvasClientSharedSurface was re-created, but GLScreenBuffer was not re-created. And RenderCompositorEGL::Pause() detaches all SurfaceTesxtures, but RenderAndroidSurfaceTextureHostOGL did not handle it.
Differential Revision: https://phabricator.services.mozilla.com/D70667
--HG--
extra : moz-landing-system : lando
This code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
--HG--
extra : moz-landing-system : lando
We need to access the contents of pipeline layouts on CPU
when we are recording commands. This PR adds refcounting to them
and improves the destruction code path to happen once all references are gone.
Differential Revision: https://phabricator.services.mozilla.com/D70868
--HG--
extra : moz-landing-system : lando
Previously we were using 256 bytes (which happens to be equal to 64
pixels for RGBA8 textures). A recent change to the GPU Cache uncovered
the fact that the requirement is actually 64 pixels, eg 1024 bytes for
RGBAF32 textures.
Differential Revision: https://phabricator.services.mozilla.com/D70915
--HG--
extra : moz-landing-system : lando
This also adds checks for the other side closing during the ReturnRead and
ReturnWrite loops.
Depends on D70336
Differential Revision: https://phabricator.services.mozilla.com/D70337
--HG--
extra : moz-landing-system : lando
This fixes an issue with the AboutToWait check. It is possible that this could
be done without this, but while there might be a very slight performance hit, it
seems to be smaller than the general noise in the tests.
Depends on D70335
Differential Revision: https://phabricator.services.mozilla.com/D70336
--HG--
extra : moz-landing-system : lando
it was a bogus warning that erroneously fire when Gecko flushed mapped contents
Differential Revision: https://phabricator.services.mozilla.com/D70789
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
These just wrap regular std Sender/Receiver without providing any value. Serialize/Deserialize was implement manually for MsgSender/MsgReceiver to assert. Serde being amazing, it provides with annotations to not require the traits to be implemented on some enum variants and assert at runtime which functionally equivalent but less error-prone than the fake trait implementations.
Removing the rest of channel.rs is coming in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D70021
--HG--
extra : moz-landing-system : lando
Only drop targets from the render target pool when the size of
the pool is larger than an arbitrary threshold (this is 32 MB
for now), _and_ the render target hasn't been used in the last
60 frames of rendering.
This reduces the number of allocation thrashing of textures in
the render target pool on most pages.
Differential Revision: https://phabricator.services.mozilla.com/D70782
--HG--
extra : moz-landing-system : lando
The basic problem here for the page is that we should draw an svg element as if it has no mask specified if the specified mask is display: none. (For html elements in the same situation we should not draw the html element at all.)
The fix is to treat the return values of PaintMaskSurface (which come through nsSVGIntegrationUtils::PaintMask and nsDisplayMasksAndClipPaths::PaintMask) in WebRenderCommandBuilder::BuildWrMaskImage the same way as in CreateAndPaintMaskSurface.
Differential Revision: https://phabricator.services.mozilla.com/D70596
--HG--
extra : moz-landing-system : lando
The WR code that computed the sticky_offset didn't properly combine the offsets
from the top- and bottom- sticky calculations if an item had both. This patch
fixes the calculation, which makes the remaining test failure (in the
configuration without any dynamic toolbar) pass.
Depends on D70679
Differential Revision: https://phabricator.services.mozilla.com/D70680
--HG--
extra : moz-landing-system : lando
These assertions don't hold in some perfectly legitimate cases, such as when
items have both top and bottom sticky behaviours. The actual behaviour still
seems ok, so let's just drop the assertions.
Differential Revision: https://phabricator.services.mozilla.com/D70459
--HG--
extra : moz-landing-system : lando
Previously, the prim origin needed to be stored in the prim
instance, to avoid picture cache invalidations. With support
for external scroll offset, this is no longer necessary.
This simplifies some of the code paths, and reduces the size
of primitive instances.
Differential Revision: https://phabricator.services.mozilla.com/D70740
--HG--
extra : moz-landing-system : lando
On some (primarily older, integrated) drivers, we see significant
time in CPU stalls during updates to the vertex data textures.
As a short term fix, this patch creates an array of vertex data
textures, and rotates which set of them are in use each frame.
There are better long-term options (such as porting the GPU cache
scatter method, or perhaps using UBO/SSBOs here), but this is a
simple workaround for now.
Differential Revision: https://phabricator.services.mozilla.com/D70775
--HG--
extra : moz-landing-system : lando
This isn't used any more; the only getter function is not called from
anywhere.
Depends on D70602
Differential Revision: https://phabricator.services.mozilla.com/D70603
--HG--
extra : moz-landing-system : lando
For the case where we got a hit-result with a NULL_SCROLL_ID, we wouldn't
get a node, and would fall back to the root APZC for the layers id. But we
should actually still find the HTTN so that we can check the override flags.
Differential Revision: https://phabricator.services.mozilla.com/D70396
--HG--
extra : moz-landing-system : lando
We need to propagate the flags from the reflayer into the descendant subtree,
but remove the flag from the HTTN corresponding to the reflayer itself. See
comments in the patch for why.
Differential Revision: https://phabricator.services.mozilla.com/D70395
--HG--
extra : moz-landing-system : lando
This is a "naive" implementation that will be refined in the next couple of
patches.
Differential Revision: https://phabricator.services.mozilla.com/D69203
--HG--
extra : moz-landing-system : lando
No functional changes here, just plumbing to allow the caller to
access all the results instead of just the one picked out by
bindings.rs.
Differential Revision: https://phabricator.services.mozilla.com/D69202
--HG--
extra : moz-landing-system : lando
WebRender could be used when WebRender does not use ANGLE. And there is a case that we want to use WebRender with ANGLE for testing.
Differential Revision: https://phabricator.services.mozilla.com/D69771
--HG--
extra : moz-landing-system : lando
On some (mostly older, integrated) GPUs, the normal GPU texture cache
update path doesn't work well when running on ANGLE, causing CPU stalls
inside D3D and/or the GPU driver. To reduce the number of code paths we
have active that require testing, we will enable the GPU cache scatter
update path on all devices running with ANGLE. We want a better solution
long-term, but for now this is a significant performance improvement on
HD4600 era GPUs, and shouldn't hurt performance in a noticeable way on
other systems running under ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D70764
--HG--
extra : moz-landing-system : lando
PaintMaskSurface shouldn't be applying ImgDrawResult::NOT_READY when we don't have a frame and the mask image hasn't been resolved. ImgDrawResult is only about drawing images, not about waiting for external resources to resolve or frames to get constructed. The only purpose of tracking ImgDrawResult's in painting code is to know which frames we need to invalidate because their rendering might change if we sync decode images during a Draw call. Applying NOT_READY here means we invalidate for every paint with the sync decode images flag (ie reftest paints), and it never changes from NOT_READY. This bites the reftest for this bug 1624532.
To fix it, instead of "overloading" the ImgDrawResult we return a bool to indicate the mask is missing or incomplete.
Differential Revision: https://phabricator.services.mozilla.com/D70595
--HG--
extra : moz-landing-system : lando
Previously, it was possible for a tile that had a valid scroll root
to have an empty valid (and dirty) rect due to the picture cache
clip rect, in some situations.
This could result in the tile not being tagged as off-screen, which
means it is added to the queue of tiles to be updated. On most
platforms this is benign, but the BeginDraw method of DirectComposition
fails if the dirty rect is empty.
This patch fixes the logic so that tiles that meet these conditions
are correctly tagged as not visible, and skipped from update queue.
Differential Revision: https://phabricator.services.mozilla.com/D70616
--HG--
extra : moz-landing-system : lando
