We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
This moves the IPC mechanism from PCompositorBridge to PLayerTransaction/
PWebRenderBridge, so that it can be used by content processes like the other
test APIs. It still only produces actual data for the layers backend; for
WR it will just return empty datasets.
Differential Revision: https://phabricator.services.mozilla.com/D86016
Previously, the content_size was used when defining an iframe
to set the size of the root scrollable area.
However, this was never useful (the root pipeline scroll frame
is not considered a scroll root, it's more of a placeholder).
The scroll frame for content is typically defined within the
iframe display list (which also allows non-scrolled content
within the iframe, such as a background rectangle color).
The existing content_size was causing problems in Gecko because
there are some snapping / rounding inaccuracies with fractional
DPI ratios, resulting in root scroll frames with +/- 1 pixel
scrollable size.
The simplest fix for this is to remove content_size altogether
and rely on the iframe display item to define the content size
of the root scroll frame for a pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D85719
The extra_data_offset wasn't being set properly in the built display list's
descriptor, so no items were being found. With that fixed it became evident
that we need to disable the display list item cache for dumping to work, since
we can't easily look up reuse items when doing the interleaved dumping. So
this patch also adds some machinery for that.
Differential Revision: https://phabricator.services.mozilla.com/D83778
When DWM is disabled, each window does not have own back buffer. They would paint directly to a buffer that was to be displayed by the video card. WM_PAINT via SendInvalidRegion() requests necessary re-paint. With it, RenderCompositorANGLE does not need to disable partial present.
Differential Revision: https://phabricator.services.mozilla.com/D77989
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
