When using the native RenderCompositor+SWGL on MacOS, we don't support passing buffer textures directly to the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D93179
By Bug 1661189, AndroidHardwareBuffer owning TextureHosts became to be stored in mTextureHostsUntilRenderSubmitted.
AndroidHardwareBuffer usage is not enabled on gecko.
Differential Revision: https://phabricator.services.mozilla.com/D93050
gfxVars::UseWebRenderDCompVideoOverlayWin() could be changed from true to false, when DCompVideoOverlay task is failed. In this case, DisplayItems need to be re-pushed to WebRender for disabling video overlay.
If DisplayItem is not re-pushed, overlay video rendering is not updated.
Differential Revision: https://phabricator.services.mozilla.com/D90656
Release fence is delivered from RenderCompositorEGL to WebRenderImageHost via AsyncImagePipelineManager. And the fence is sent to client side by ImageBridgeParent.
Differential Revision: https://phabricator.services.mozilla.com/D88158
The following functions are asynchronously called by a bit different ways. It seems not good. It seems better to unify them.
PrepareForUse()
NofityForUse()
NotifyNotUsed()
Differential Revision: https://phabricator.services.mozilla.com/D87709
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
When a transform depends on the layout size of an element, one can see
visual distortions caused by the difference between the unsnapped size
used in the transform, and the snapped size calculated during scene
building. Ideally we could compute the transform after we snap, rather
than before. This patch adds support for a computed reference frame
which takes parameters to calculate the ideal transform dynamically.
In a future patch, we should make videos take advantage of this same
mechanism to avoid similar problems. This requires support for mirroring
and rotations.
Differential Revision: https://phabricator.services.mozilla.com/D77956
By using RenderTextureHostWrapper, we could reduce re-creation of RenderDXGITextureHostOGL and RenderDXGIYCbCrTextureHostOGL.
Differential Revision: https://phabricator.services.mozilla.com/D74838
There could be a case that new RenderThread::PrepareForUse() and new WebRender transaction by WebRenderBridgeParent::MaybeGenerateFrame() achieve during calling UpdateAndRender().
Differential Revision: https://phabricator.services.mozilla.com/D74365
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
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
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
The code is untested, and mostly obsoleted by (multi) frame captures.
Also it gets in the way of some other changes I need to make.
Differential Revision: https://phabricator.services.mozilla.com/D71372
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
Removes NofityForUse() functions for simplicity.
Ensure that RenderTextureHost::PrepareForUse() is called before RenderTextureHost:: Lock(). When a task of calling RenderTextureHost::PrepareForUse() is simply posted to render thread, there is a case that RenderTextureHost:: Lock() is called before PrepareForUse() .
Differential Revision: https://phabricator.services.mozilla.com/D51974
This replaces mUpdatesCount in AsyncImagePipelineManager, which was really how
many times NotifyPipelinesUpdated was called with aRender == true. I think this
makes the release logic clearer as it is more explicit.
It also changes things for RenderCompositorANGLE, so that we check to see if
any other frames have completed even if we don't want to wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D51064
When high contrast mode is enabled, title bar is drawn as transparent and on-client area rendering by DWM is shown. But when compositor window in GPU process is used, the on-client area rendering was not shown. To address the proboem, window needs to be cleard as transparent and SwapChain of compositor window needs to be DXGI_ALPHA_MODE_PREMULTIPLIED.
WinCompositorWidget::mTransparencyMode is changed to atomic, since it is accessed from compositor thread and render thread.
Differential Revision: https://phabricator.services.mozilla.com/D48302
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
