TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
This basically allowed managing a bunch of scroll data things in parallel
for all the render roots which we don't need anymore.
Differential Revision: https://phabricator.services.mozilla.com/D69845
Nothing creates the content render root anymore, so we can delete
references to it and wipe it off the face of the codebase. This makes
the non-default render root array a zero-length Array which is a template
specialization that lacks things like begin() end end(). So we need
to also rip out any code that tries to iterate these things, in order
to get compilation to succeed. The code would be a no-op anyway now
that there are no non-default render roots left.
Depends on D68864
Differential Revision: https://phabricator.services.mozilla.com/D68865
This is needed because display lists and DisplayItemCache have different lifetimes. For example, display lists can outlive WebRenderLayerManager when device reset occurs.
A slightly nicer way of fixing this would be to couple DisplayItemCache with nsDisplayList or nsDisplayListBuilder. This is would currently require a lot of refactoring to look nice, because the painting code still supports non-retained display lists and non-WR code paths.
Differential Revision: https://phabricator.services.mozilla.com/D68193
DisplayItemBuilder now has methods:
```
void StartGroup(nsPaintedDisplayItem* aItem);
void CancelGroup();
void FinishGroup();
bool ReuseItem(nsPaintedDisplayItem* aItem);
```
WebRender display items previously created between calls to StartGroup() and FinishGroup() will be reused by a call to ReuseItem(),
which will push DisplayItem::ReuseItem(key) to WR display list, if the Gecko display item has been retained and reused.
Calling CancelGroup() will discard the display items that have been pushed after calling StartGroup().
For example, inside nsDisplayBackgroundColor::CreateWebRenderCommands():
```
aBuilder.StartGroup(this);
aBuilder.PushRect(r, r, !BackfaceIsHidden(),
wr::ToColorF(ToDeviceColor(mColor)));
aBuilder.FinishGroup();
```
Differential Revision: https://phabricator.services.mozilla.com/D65356
DisplayItemBuilder now has methods:
```
void StartGroup(nsPaintedDisplayItem* aItem);
void CancelGroup();
void FinishGroup();
bool ReuseItem(nsPaintedDisplayItem* aItem);
```
WebRender display items previously created between calls to StartGroup() and FinishGroup() will be reused by a call to ReuseItem(),
which will push DisplayItem::ReuseItem(key) to WR display list, if the Gecko display item has been retained and reused.
Calling CancelGroup() will discard the display items that have been pushed after calling StartGroup().
For example, inside nsDisplayBackgroundColor::CreateWebRenderCommands():
```
aBuilder.StartGroup(this);
aBuilder.PushRect(r, r, !BackfaceIsHidden(),
wr::ToColorF(ToDeviceColor(mColor)));
aBuilder.FinishGroup();
```
Differential Revision: https://phabricator.services.mozilla.com/D65356
I think this probably only shows up with fission oop iframes, tabs probably avoid this path.
The problem occurs when we reconstruct the containing iframe for a style change, we briefly hide the child document, clearing the display list on the parent via ClearCachedResources. Then show it again, we attempt an empty transaction and this succeeds because there is nothing to stop it. (The non-wr case fails because the layer contents are missing and that causes the empty transaction to fail.)
So keep track if we have sent a display list to the parent to allow/disallow an empty transaction.
This fixes a couple webrender+fission reftest failures but it's also a general rendering bug in webrender+fission reproducible in a regular browser.
Differential Revision: https://phabricator.services.mozilla.com/D61577
I think this probably only shows up with fission oop iframes, tabs probably avoid this path.
The problem occurs when we reconstruct the containing iframe for a style change, we briefly hide the child document, clearing the display list on the parent via ClearCachedResources. Then show it again, we attempt an empty transaction and this succeeds because there is nothing to stop it. (The non-wr case fails because the layer contents are missing and that causes the empty transaction to fail.)
So keep track if we have sent a display list to the parent to allow/disallow an empty transaction.
This fixes a couple webrender+fission reftest failures but it's also a general rendering bug in webrender+fission reproducible in a regular browser.
Differential Revision: https://phabricator.services.mozilla.com/D61577
SyncObjectD3D11Host::Synchronize() calling in RenderCompositorANGLE::BeginFrame() is still necessary for D3D11DXVA2Manager::CopyToImage(). Then backout Bug 1596630.
Differential Revision: https://phabricator.services.mozilla.com/D61658
mSyncObject->Synchronize() was necessary to handle a case that D3D Texture was created on main thread of content process and the Texture does not have a keyed mutex. But with WebRender, the situation does not happen often. Further the Synchronize() is sometimes very slow. Therefore it is better to remove it from RenderCompositorANGLE::BeginFrame().
Canvas 2d does not use keyed mutex yet. Then the change adds keyed mutex usage for the canvas 2d.
D3D11DXVA2Manager still uses the Synchronize(). In this case, the Synchronize() is manually called in D3D11DXVA2Manager::CopyToImage(). Then RenderCompositorANGLE still needs to create SyncObjectHost.
Differential Revision: https://phabricator.services.mozilla.com/D53168
EGL_ANGLE_experimental_present_path was enabled for fast rendering to SwapChain by ANGLE. But current gecko does not request ANGLE to render to SwapChain for WebRender. Then we do not need to use EGL_ANGLE_experimental_present_path anymore. But Its usage still has a side effect that y is flipped. But OS compositor implementation on Windows does not want it. And it seems not good to continue to use EGL_ANGLE_experimental_present_path since it is experimental feature.
But when EGL_ANGLE_experimental_present_path is removed, rendering result of frame buffer is y flipped with ANGLE compared to other OpenGL implementation. It needs to be handled in WR. It is similar to chromium.
Differential Revision: https://phabricator.services.mozilla.com/D50604
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
RecordedTextureData records TextureData calls for play back in the GPU process.
CanvasChild and CanvasParent set up the recorder and translator.
They also help to manage the starting of translation and co-ordinating the
translation with the frame transactions.
This patch also includes other changes to wire up recording and playback.
