The only caveat here is that gfxVars are not atomic, but multiple threads can
query DWM status. To solve this, changes to the var are mirrored into an atomic
and that is read instead.
DWM status changes are indicated by Windows via a window message. We use that
window message to cause the update to propagate
Differential Revision: https://phabricator.services.mozilla.com/D73743
Currently, There are multiple places that call the Win32 APIs for DWM status.
Once Win32k lockdown is enabled, this API will be unavailable and will need
to be remoted. This new function will be made to work in both parent and
content processes, and therefore all DWM queries must be directed to it.
Also, some minor cleanup because... Why not?
Differential Revision: https://phabricator.services.mozilla.com/D73742
THis should continue allowing users to zoom out in RDM mode, or any time that
we are respecting the meta-viewport tag. It's only when we don't respect the
meta-viewport tag that we disable zooming out past initial zoom.
Differential Revision: https://phabricator.services.mozilla.com/D73461
Currently, there is an outstanding issue where enabling the GPU sandbox breaks
scrolling using the the mouse wheel on laptops with Intel GPUs.
This will enable the GPU sandbox on Nightly for non-Intel GPUs to prevent any
sandbox regressions while we try and figure out what the scrolling issue is.
See Bug 1630860 for more info
Differential Revision: https://phabricator.services.mozilla.com/D73923
The spatial node index and clip chain id are no longer directly
related concepts, since they now exist in different representations
(the spatial tree and clip store).
Removing the grouping of these during scene building simplifies
some work in progress to refactor how WR internally represents
clips, in order to allow future optimization work.
Differential Revision: https://phabricator.services.mozilla.com/D73187
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This is the anti-climactic end of the patch series.
I set out in this bug to get this test case to pass with apz.allow_zooming.
It took all these changes to do so without regressing other tests.
Differential Revision: https://phabricator.services.mozilla.com/D69644
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
The implementation was already only using the scroll id, so there is no
functional change, but this change will make it easier to new call sites
to come up with the function's inputs.
Differential Revision: https://phabricator.services.mozilla.com/D68277
This is to facilitate call sites that need to incorporate the transform into
a larger transform matrix rather than immediately applying the callback
transform to a point.
Differential Revision: https://phabricator.services.mozilla.com/D68275
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
This is a bigger patch but it was hard to split. Some of the changes look
non-trivial; the guiding principle in these changes was "look at what the code
was like before document splitting landed".
Differential Revision: https://phabricator.services.mozilla.com/D73879
I had to mess with the refcounting of Display (and hence destructors) because we create a NewRunnableMethod inside Display that holds a pointer to |this|. There are versions of NewRunnableMethod that don't take a ref but I'm not sure of the lifetime of Display, so easier to just take a ref since several of the subclasses are already refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D71303
Previously, WR would internally mark a parent stacking context
as requiring isolation when a stacking context with mix-blend-mode
was encountered.
However, this adds significant complexity to scene building in
WR, meaning that several decisions related to stacking context
redundancy, clip chain roots must be delayed until the stacking
context is popped.
By requiring the display list to annotate blend containers (Gecko
already has all this information available), we will be able to
simplify this scene building logic, which will unblock some
ongoing improvements to how clips are handled.
The patch introduces stacking context flags, and ports the existing
is_backdrop_root bool to be part of these flags. It also removes
an unused old field, cache_tiles.
Differential Revision: https://phabricator.services.mozilla.com/D73597
Part 1 - support RGB external surfaces for promotion to compositor
surfaces; add new shader permutations to handle all buffer kinds.
Set the promotion flag when the pixel format has no alpha, or when the
texture provider can guarantee all-solid alpha values.
Differential Revision: https://phabricator.services.mozilla.com/D71120
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
The internal logic accesses adapters during command recording.
This PR makes up to keep that reference for while the device lives.
Differential Revision: https://phabricator.services.mozilla.com/D73278
Currently SWGL stores separate copies of flat interpolants, uniforms, and samplers for vertex shaders and fragment shaders. We can just make the fragment shader inherit from the vertex shader, which allows us to only have to store one copy of these, and also obviates the need to store them out and read them back to transition from vertex shader to fragment shader per-primitive. This will help offset the performance cost of perspective checking in bug 1634447.
Differential Revision: https://phabricator.services.mozilla.com/D73299
Based on ideas discussed to solve bug 1633912, this patch implements allowing each shader to switch between no-perspective and perspective on per-primitive based on whether or not the primitive's W coordinates all match. This should be a sufficient stop-gap for now to unblock testing and development. Performance and memory usage costs of this approach will need to be evaluated before we decide whether to keep it long term.
Differential Revision: https://phabricator.services.mozilla.com/D73298
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
* Templatize ProducerView/ConsumerView/(Sync)CommandSource/(Sync)CommandSink to allow both Pcq and Ipdl versions, as the client code is identical.
* Rename Producer/Consumer -> PcqProducer/PcqConsumer.
Differential Revision: https://phabricator.services.mozilla.com/D68259
The implementation of this was previously ignoring the aRegion
parameter, so was completely broken. This is only used by the
Win7 widget code. This may fix an issue with drawing of window
close buttons on Windows 7 with WebRender enabled.
Differential Revision: https://phabricator.services.mozilla.com/D73163
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
* Templatize ProducerView/ConsumerView/(Sync)CommandSource/(Sync)CommandSink to allow both Pcq and Ipdl versions, as the client code is identical.
* Rename Producer/Consumer -> PcqProducer/PcqConsumer.
Differential Revision: https://phabricator.services.mozilla.com/D68259
In particular this will pick up any hit-test flags set on individual items
inside a blob, and ensure the hit-test info emitted to APZ for the blob includes
those flags.
Differential Revision: https://phabricator.services.mozilla.com/D69205
It's no longer needed with the recent fix to how rectangle prim
and clip rects are stored. It's also a performance win, reducing
the amount of work done when comparing primitive dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D72794
It's no longer needed with the recent fix to how rectangle prim
and clip rects are stored. It's also a performance win, reducing
the amount of work done when comparing primitive dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D72794
In particular this will pick up any hit-test flags set on individual items
inside a blob, and ensure the hit-test info emitted to APZ for the blob includes
those flags.
Differential Revision: https://phabricator.services.mozilla.com/D69205
Part 1 - support RGB external surfaces for promotion to compositor
surfaces; add new shader permutations to handle all buffer kinds.
Set the promotion flag when the pixel format has no alpha, or when the
texture provider can guarantee all-solid alpha values.
Differential Revision: https://phabricator.services.mozilla.com/D71120
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This is the anti-climactic end of the patch series.
I set out in this bug to get this test case to pass with apz.allow_zooming.
It took all these changes to do so without regressing other tests.
Differential Revision: https://phabricator.services.mozilla.com/D69644
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
The implementation was already only using the scroll id, so there is no
functional change, but this change will make it easier to new call sites
to come up with the function's inputs.
Differential Revision: https://phabricator.services.mozilla.com/D68277
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
This is to facilitate call sites that need to incorporate the transform into
a larger transform matrix rather than immediately applying the callback
transform to a point.
Differential Revision: https://phabricator.services.mozilla.com/D68275
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
The RenderBackend can be sent an `invalidate_rendered_frame` flag to
indicate that the current rendered frame is invalid. This is useful
when the platform requires a render, eg when starting or resuming the
app on Android. Upon receiving this flag, the render backend will set
a variable `doc.rendered_frame_is_valid = false`. Later on it will
decide to skip rendering only if this variable is true, so by setting
the invalidate flag we should be able to ensure the next render will
occur.
However, the RenderBackend also tries to skip renders which it
determines are not required. Currently it does this by setting
`doc.rendered_frame_is_valid = true` if it decides the frame is a
no-op. This overwrites the previous value set by the
`invalidate_rendered_frame` flag, meaning webrender skips renderering
even though the platform has requested it.
This was resulting in the GVE app showing a black screen on startup,
and Fenix temporarily showing a black screen whilst opening a new tab,
because despite WebRenderBridgeParent requesting an invalidation
immediately on startup, webrender ignored that request until it
decided it actually had content to paint.
To fix this, the logic should be flipped. The value of
`doc.rendered_frame_is_valid` must be remembered across document
updates rather than defaulting to false. And instead of setting it
true if webrender thinks the frame is a no-op, we must set it false if
webrender thinks the frame is *not* a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D72600
Yura Zenevich
Chris Martin
Kartikaya Gupta
Simon Giesecke
Hiroyuki Ikezoe
Glenn Watson
Botond Ballo
Razvan Maries
Stephen A Pohl
Dzmitry Malyshau
Bert Peers
Dorel Luca
Jonathan Kew
Andrew Osmond
Timothy Nikkel
Cosmin Sabou
Daosheng Mu
Lee Salzman
David Parks
Jamie Nicol
Daniel Varga
Miko Mynttinen
Geoff Brown
Brindusan Cristian
Csoregi Natalia
Josh Matthews