Before Win32k Lockdown, Canvas would ensure that it would get the fastest possible implementation by initializing
devices in content process before allocating persistent buffers for its backing.
However, with Win32k Lockdown it's no longer possible, as initializing Direct3D and Direct2D make Win32k calls that
crash the locked-down content process.
This issue is generally solved by Remote Canvas; however, Remote Canvas is disabled if the GPU process is disabled.
If that happens, the current behavior is to attempt to initialize hardware acceleration again, causing a crash when
Win32k Lockdown is in effect.
This patch changes the behavior so that the devices will not initialize if they are in a locked-down content process,
even if Remote Canvas is disabled. The effect is that Canvas will fall back to using Skia for everything.
Differential Revision: https://phabricator.services.mozilla.com/D126761
Fix a bug where the display item cache was not being reused from
frame to frame with retained display list builders.
At the same time, make the capacity recycling on the display list
serialization arrays a bit more realistic.
Differential Revision: https://phabricator.services.mozilla.com/D124412
When device reset happens, WebRender and WebRenderLayerManagers are re-created. In this case, pending transactions of nsRefreshDriver need to be cleared during destroying WebRenderLayerManager.
Differential Revision: https://phabricator.services.mozilla.com/D124011
This will allow storing state in a display list builder struct
between different display list builds. In time, this will be used
to reduce the size of the serialized display list data, by only
sending delta changes to WR. The extra information made available
by sending deltas will then allow WR to more efficiently cache and
reuse information across different scene/frame builds.
Differential Revision: https://phabricator.services.mozilla.com/D123579
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
Move the extra_data to be a specific cache_data separate vec in
the display list payload.
This shouldn't change any functionality, but serves as a proof
of concept for future changes which will introduce several other
separated payload vectors.
Differential Revision: https://phabricator.services.mozilla.com/D121937
When the ID namespace changes for a WebRenderBridgeChild, all bindings
from that namespace are now invalid. We already drop any outstanding
async animation holds on surfaces for recycling, but we still would try
to send out async resource updates that were already queued before the
namespace was changed. This patch forces us to drop those now defunct
transactions.
Differential Revision: https://phabricator.services.mozilla.com/D108481
This also adds related DLLs to be delay loaded to xul's moz.build. This means
that if we don't create the devices they are not loaded at all.
Differential Revision: https://phabricator.services.mozilla.com/D105630
When we change the namespace, we discard all cached resources and their
associated keys from the WebRender cache. As such if any transaction
comes in with the old namespace ID, we can safefully discard the entire
update, since we will need to recreate any that we are using anyways.
This patch also adds new asserts to ensure we never get old namespace
IDs for individual keys in a valid resource update. This should never
happen in practice.
Differential Revision: https://phabricator.services.mozilla.com/D104236
When we change the namespace, we discard all cached resources and their
associated keys from the WebRender cache. As such if any transaction
comes in with the old namespace ID, we can safefully discard the entire
update, since we will need to recreate any that we are using anyways.
This patch also adds new asserts to ensure we never get old namespace
IDs for individual keys in a valid resource update. This should never
happen in practice.
Differential Revision: https://phabricator.services.mozilla.com/D104236
Popup widgets are easier to detect because the "window" widget and the "view"
widget for them are the same object.
With toplevel widgets, most platforms (IIRC all non-Windows platforms) have
separate nsIWidget objects for the "window" widget (toplevel) and the "view"
widget (child), and this code has a reference to the view / child widget.
Differential Revision: https://phabricator.services.mozilla.com/D101062
In bug 1674935 we encountered a situation where NotifyApzTransaction was called more than once on a scroll frame in one paint transaction, clearing the scroll updates before they should have been. In that bug I moved the NotifyApzTransaction calls to happen at the end of one transaction for the non-wr code path., but I left the wr code path alone to reduce risk becase we didn't have proof the same could happen with wr. In this bug I will change how the wr code path works to ensure that this problem cannot happen.
Differential Revision: https://phabricator.services.mozilla.com/D96165
This makes the WebRenderScrollData dump more analogous to the layer tree dump,
in that it prints the layer entries one per line showing in-order nested tree
structure. It also omits printing things if they're not important.
Differential Revision: https://phabricator.services.mozilla.com/D96312
This backs out part of bug 1656211 which turned out to be insufficient.
The invalidate rendered frame transaction races with the initial frame
rendering of the popup. If it comes in too soon, we will only draw the
frame once, and the frame corruption remains. This patch makes us flush
the rendering pipeline to ensure we get two separate generate frame
events.
Differential Revision: https://phabricator.services.mozilla.com/D96157
