wl_egl_window size must exactly march GL rendering pipeline setting.
Compositor and widget can have different window sizes during window resize when widget
is resized faster than layout can render. Firefox window is rendered misplaced then
and it's "jumping" as layout size is behind toolkit size.
Differential Revision: https://phabricator.services.mozilla.com/D49136
--HG--
extra : moz-landing-system : lando
wl_egl_window size must exactly march GL rendering pipeline setting.
Compositor and widget can have different window sizes during window resize when widget
is resized faster than layout can render. Firefox window is rendered misplaced then
and it's "jumping" as layout size is behind toolkit size.
Differential Revision: https://phabricator.services.mozilla.com/D49136
--HG--
extra : moz-landing-system : lando
From https://drafts.csswg.org/css-overflow/#overflow-propagation:
> UAs must apply the overflow-* values set on the root element to the viewport.
> However, when the root element is an [HTML] html element (including XML syntax
> for HTML) whose overflow value is visible (in both axes), and that element has
> a body element as a child, user agents must instead apply the overflow-*
> values of the first such child element to the viewport. The element from which
> the value is propagated must then have a used overflow value of visible.
This was out of sync with Document::IsScrollingElement, which implements the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D49196
--HG--
extra : moz-landing-system : lando
From https://drafts.csswg.org/css-overflow/#overflow-propagation:
> UAs must apply the overflow-* values set on the root element to the viewport.
> However, when the root element is an [HTML] html element (including XML syntax
> for HTML) whose overflow value is visible (in both axes), and that element has
> a body element as a child, user agents must instead apply the overflow-*
> values of the first such child element to the viewport. The element from which
> the value is propagated must then have a used overflow value of visible.
This was out of sync with Document::IsScrollingElement, which implements the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D49196
--HG--
extra : moz-landing-system : lando
Instead of allocating a tile surface from the texture cache during
the tile post_update method, this is now deferred until the
take_context method of picture.
This will allow a simple CPU occlusion culling pass to run after
all the tile cache dependency updates (when the visible tiles and
rects are know), but before the surfaces are allocated. In this way,
we will be able to skip allocating, rasterizing and compositing
any tiles that are eliminated by the occlusion culling test.
Differential Revision: https://phabricator.services.mozilla.com/D48795
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--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
Notify VRActiveStatus after a the VREventObserver is created to prevent the VRManagerParent::GetVRActiveStatus race condition.
Call VRManager::Shutdown() when the app goes to background instead of calling it in the foreground event due to the inactivity timer.
Differential Revision: https://phabricator.services.mozilla.com/D48678
--HG--
extra : moz-landing-system : lando
This patch adds a notion of "fully transparent" image in the resource cache.
These are not uploaded in the texture cache and image requests return the
necessary information to allow the frame building code to skip emitting
primitives accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D47878
--HG--
extra : moz-landing-system : lando
Since Bug 1570879, SwapChain is created with alpha at first, then the SwapChain is typically re-created at first RenderCompositorANGLE::BeginFrame() calle, since non Glass window is common since Windows 10. The re-creation is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D48800
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--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
IDCompositionDevice is replaced by IDCompositionDevice2. It is necessary for IDCompositionDeviceDebug usage. And for using IDCompositionDevice2, _WIN32_WINNT and NTDDI_VERSION is updated from Windows 8 to Windows 8.1.
Workaround MinGW build failure.
Differential Revision: https://phabricator.services.mozilla.com/D47742
--HG--
extra : moz-landing-system : lando
The previous patch fixed the bug in the non-picture caching code
path, so we can re-enable the preference now.
Differential Revision: https://phabricator.services.mozilla.com/D48639
--HG--
extra : moz-landing-system : lando
When uploading texture data with a PBO we currently ensure the PBO
is the size of `(height - 1) * stride + (width * bpp)`, ie the final row
only contains the width's worth of data, not the stride. This should
be okay, and works fine on other implementations, but the android
emulator thinks it is invalid and emits a GL_INVALID_OPERATION error
in the glTexSubImage* call. To avoid this, ensure that the PBO is the
full `height * stride` size.
Differential Revision: https://phabricator.services.mozilla.com/D48541
--HG--
extra : moz-landing-system : lando
The framebuffer clear was accidentally removed due to a rebase
error. We need to clear the framebuffer (and z) here when the
non-picture caching path is active.
Differential Revision: https://phabricator.services.mozilla.com/D48600
--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
The CanvasChild must be in the process of being destroyed at this point anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47443
--HG--
extra : moz-landing-system : lando
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
--HG--
extra : moz-landing-system : lando
Populating them is hooked up for non-WebRender, with a comment outlining
possible implementation strategies for WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D48384
--HG--
extra : moz-landing-system : lando
