This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: 1wBFnJnYCwC
--HG--
extra : rebase_source : 542f814af9369fe712af76fc2a8c78de26c6227f
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: BA83Sy9UjYH
--HG--
extra : rebase_source : 15e5b31d0275628713c5eb584d622d22485dfda9
This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: Cu1K3rLjm0V
--HG--
extra : rebase_source : b5994faceb9dd7e52222714bdbc5b06886d26415
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: KyabB6P6LiA
--HG--
extra : rebase_source : d5fff8f21a17c433d3c8c580fdd3153140d61545
gfxContext::PushGroupAndCopyBackground & PushGroupForBlendBack do not change the
content of AzureState, we should remove gfxContext::Save in these two functions.
MozReview-Commit-ID: LUuC7bkqFba
--HG--
extra : rebase_source : bed69fa8544e389f4ac13a63489a215a6c86d632
Since gfxContext::Save keep appear on my screen when I did profile, so I think
we should find a way to prevent unecessary usage of this function.
By this patch, an assertion message will be dump if we save and restore an
unchanged AzureState.
MozReview-Commit-ID: 5lH1Y5T5K7t
--HG--
extra : rebase_source : 3fe0bb72ad78273687008cdf87692090cf3fe931
With DXVA2 hardware-video-decoding, the RendererOGL should have a
synchronization mechanism to prevent the flickering of video texture.
Create a SyncObject in RendererOGL to do the texture synchronization.
The WebRenderAPI also exposes the RendererOGL's SyncHandle to
WebRenderBridgeParent. Then, the WebRenderBridgeParent could pass this SyncHandle
to the video decoding module for texture synchronization.
MozReview-Commit-ID: toQ2mO5fzG
From bug 1163440, there is an additional AcquireSync() call around the swapChain::Present(). Export the KeyedMutex from SyncObjectD3D11Host for this synchronization.
MozReview-Commit-ID: 8mPs4jKj67W
The MLGDeviceD3D11, CompositorD3D11 and TextureClient use the same synchronization mechanism.
Create the new SyncObjectClient/Host types for reusing code.
Add SyncObject.cpp/h and create two new data types: SyncObjectClient and SyncObjectHost.
The SyncObjectClient is used for the TextureClient synchronization at client side.
The SyncObjectHost is used for the TextureHost synchronization in renderers such
as MLGDeviceD3D11 and CompositorD3D11.
MozReview-Commit-ID: 3l56WK1aZ15
Create the corresponding RenderTextureHost type and WR commands for DXGI texture type.
The DXGITextureHostD3D11 will use 1 or 2 image keys for non-nv12 and nv12 texture format.
The DXGIYCbCrTextureHostD3D11 is a special case. The WR uses ANGLE in windows platform,
but the ANGLE doesn't support A8 format directx texture directly. So, we use libyuv to
convert the DXGIYCbCrTextureHostD3D11 texture buffer into RGBA format buffer and use
WR::AddImage() for that image. This is a slow code path. We will refine this case later.
The whole RenderD3D11TextureHostOGL implementation is in the next patch.
MozReview-Commit-ID: F4mPCALj1OY
All WR texture related codes are move into GetWRImageKeys(), AddWRImage() and PushExternalImage().
Each texture type could generate its WR commands individually. So, this "mIsWrappingNativeHandle" flag is not used anymore.
MozReview-Commit-ID: 1TITkGRemAr
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
Add a boolean value in FindFamily() to check if gecko needs to defer the
InitOtherFamilyNames() task into idle queue.
Add a new telemetry data FONTLIST_INITOTHERFAMILYNAMES_NO_DEFERRING for the
execution time of InitOtherFamilyNames() running regularly at main thread
instead of in idle queue.
MozReview-Commit-ID: A3YPDcHtXrX
We gave up on the iea of parallel tile rendering in favor of different approaches, so the job scheduler isn't used at all. The several seconds spend testing the job scheduler in each push is a waste of infra. In addition, rust is a better avenue to tackle this type of system.
mLastCanvasDatas store used WebRenderCanvasData in last full
transaction. So that in next empty transaction, we can update canvas
content through mLastCanvasDatas.
MozReview-Commit-ID: 2H2m8R7Kzwf
This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
When empty transaction in layers free mode, we don't rebuild whole
display list. But the canvas content will be updated and send the
content to parent by CanvasClient. We need some mechanism just like
async video which can update the content without rebuild the dl. But
CanvasClient doesn't use ImageBridge at all. So I slightly modify
AddPipelineIdForAsyncCompositable to let it support the Compostiable
either store in ImageBridge or WebRenderBridgeParent.
MozReview-Commit-ID: 3mKv13Pgc2k
Add a boolean value in FindFamily() to check if gecko needs to defer the
InitOtherFamilyNames() task into idle queue.
Add a new telemetry data FONTLIST_INITOTHERFAMILYNAMES_NO_DEFERRING for the
execution time of InitOtherFamilyNames() running regularly at main thread
instead of in idle queue.
MozReview-Commit-ID: A3YPDcHtXrX
The notification is sent via GeckoContentController, PAPZCTreeManager if
necessary (to go from the GPU process to the parent process), and the
observer service.
Naturally, the notification is not sent in the case where it's browser.xml
that initiates the shutdown.
MozReview-Commit-ID: IAaSf4HiDF4
--HG--
extra : rebase_source : 80855ac7d3ae44c393dde96650b330cc737f69d6
This commit adds the pref, 'apz.keyboard.passive-listeners', to allow web
content to have passive key event listeners and use keyboard APZ. When we are
allowing passive listeners, we need to dispatch the input to content and can
no longer consume the event. So we use mHandledByAPZ in nsXBLWindowKeyHandler
to determine whether we still need to do the default action, or whether it
has been done by APZ.
MozReview-Commit-ID: 2HAC6DjDyPZ
--HG--
extra : rebase_source : 77543ef3f28bdbb8ef77e984097ce75cdf333c82
This is for adding a pref that will allow web content to have key listeners
and use keyboard APZ, if they are marked passive. This commit also reworks
the function names and comments to make them more accurate.
MozReview-Commit-ID: LGDaVQOK1CS
--HG--
extra : rebase_source : a6bb4b7fff3488dea62b9114aa164814c74561a4
