We add the SideBits to the data we store in the FixedPosScrollTargetTracker. nsDisplayCompositorHitTestInfo then passes the side bits when it sets hit test info. We then pack the side bits into the hit test info bits; luckily they were only using 12 of 16 bits. The wr HitTest api then extracts the side bits from the hit test info bits and passes them back.
Differential Revision: https://phabricator.services.mozilla.com/D54404
--HG--
extra : moz-landing-system : lando
The plumbing from there to the HitTestingTreeNode is already in place for the non-webrender case.
Differential Revision: https://phabricator.services.mozilla.com/D54402
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This stops the potential build up of held textures during a series of empty
webrender transactions, because of a render not happening. The patch also only
sends the OpUpdatedAsyncImagePipeline command when a new texture has been
forwarded for the canvas, to prevent unnecessary invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D53223
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This also reduces the size of BlobItemData which will give us
some free performance on SVGs that have a lot of items by reducing
our working set size.
Differential Revision: https://phabricator.services.mozilla.com/D49023
--HG--
extra : moz-landing-system : lando
In the future mInvalidRect and some other state should move out of DIGroup
and into a non-persistant struct that's only used during Group building.
This will allow us to completely avoid errors like this.
Differential Revision: https://phabricator.services.mozilla.com/D48706
--HG--
extra : moz-landing-system : lando
What we actually care about here is whether itemRect is empty bceause that's
the what we'll use for the actual surface size.
Differential Revision: https://phabricator.services.mozilla.com/D48548
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This makes things better especially when the bounds of the combined blob
is changing but the bound of the separate ones are not.
The current implementation is a bit ugly, but it's simple and
can be cleaned up in the cleanups I have in mind for the future.
Differential Revision: https://phabricator.services.mozilla.com/D47983
--HG--
extra : moz-landing-system : lando
Instead of checking whether the bounds of the clipped
image has changed just check whether our clipped bounds
have changed. This simplifies the code and avoids
a bunch of extra invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D47971
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
Now that we're painting based on the visible area we need to make sure that we
update the blob when ever the visible area changes. We'll do this by
unconditionally setting the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D47335
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
sotaro
Timothy Nikkel
Bob Owen
James Hooks
Markus Stange
Nicolas Silva
Barret Rennie
Daniel Varga
Sebastian Hengst
Miko Mynttinen
Sylvestre Ledru
Kris Taeleman
Jeff Muizelaar
Jamie Nicol
Jeff Muizelaar
Botond Ballo
Brindusan Cristian
Ciure Andrei
Coroiu Cristina