During double tap animations we can be in a situation where we get two repaint requests from every layers update. The first one comes from NotifyLayersUpdated and scroll offset update type is eNone, the second from the zoom animation ticking has scroll offset update type eUserAction and there was a layout scroll position update. Both can have some amount of aync zoom (not necessarily equal), and have the same content pres shell resolution.
We handle the eNone one first, and update the content pres shell resolution. Then for the eUserAction we check the content presshell resolution and it no longer matches, so we drop the request entirely thinking its out of date (including the scroll position update). It's not out of date of course, content hasn't done any updates, so apz has the latest info (even if it might not have a fully up to date value of the content pres shell resolution, it's value of zoom is the most up to date of anywhere).
Differential Revision: https://phabricator.services.mozilla.com/D114587
This will be used by follow up patches to do some verification and
optimization of how we handle clips between different spaces.
For now, it also allows removal of the method to check if a spatial
node is definitely in a root coordinate system.
Differential Revision: https://phabricator.services.mozilla.com/D115182
When the pipeline layout is implicit at pipeline creation,
we collect the IDs of BGLs, to be able to produce GPUBindGroupLayout
object upon user request. However, the produced object didn't know if
it owns the ID or borrows it, so it would issue a "drop" when going out of scope.
This change establishes this distinction. In addition, it gets the Pipeline Layout ID,
and together with the BGL ids, they are sent to GPU process upon pipeline destruction.
When the GPU process is done with these IDs used, it will kick back a message to the
Content process, allowing the IDs to be reclaimed.
Differential Revision: https://phabricator.services.mozilla.com/D114649
In order to fully comply with the spec and work on all compositors.
This is somewhat inspired by `SurfacePoolCA`, moving buffers between
buckets - in use or available. The idea is to make it easy to expand
this further to share a common buffer pool between multiple surfaces.
It works similar to EGL buffer handling and reuses the partial damage
logic in WR by implementing buffer age.
Notable changes to the current implementation:
- always draw directly into shm-buffer memory - no caching.
- drawing is purely driven by the compositor / the VsyncSource.
No frame callbacks or threads apart from buffer release
callbacks.
One of the goals here is to handle different compositor behaviour
efficiently - if a compositor releases buffers early, we want to
reuse a single buffer whenever possible. If a compositor holds buffers
longer, we want to minimize the area we need to redraw to older buffers.
This is archived by always using the last released buffer. The expected
usual buffer age is `1` in the fast release case and `2`-`3` in the
holding case.
This changes buffer handling quite significantly, so propper testing
is due. However, as the overall architecture is somewhat simpler than
before, it may improve stability in the long term.
Note: instead of replacing, this now duplicates parts of the existing
backend. This is in order to keep the existing one stable and gruadually
phasing it out together with the Basic compositor.
Differential Revision: https://phabricator.services.mozilla.com/D114349
This gives the RegisterFonts thread more time to complete its work, so that
the main thread doesn't have to wait for it in InitFontList.
In the worst case, where the registration thread still hasn't finished
by the time we call gfxPlatformFontList::PlatformFontList() the first time,
it's still no worse than previously, it just reorders some of the work
that has to be done before we can render any content.
Depends on D114863
Differential Revision: https://phabricator.services.mozilla.com/D114865
It makes sure that overscroll animations which have been cancelled by this pan
gesture will restart again.
The reason we don't use the existing SnapBackOverscrolledApzc is that
SnapBackOverscrolledApzc function ends up calling ScrollSnap even if
it's not overscrolled, thus it will mess up subsequent momentum scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D114928
Otherwise each texture is scaled down to make room for dozens of picture tiles to the point that it's hard to make out whatever is in the textures. We can already see the texture cound via the HUD profiler so it's more useful to only show shared textures and see what's in the atlases.
Differential Revision: https://phabricator.services.mozilla.com/D115213
Cached render tasks are usually much cheaper to produce than texture uploads so it's good to make sure lingering unused render tasks don't create unnecessary pressure on the texture cache. It also avoids things like animated gradients from filling the texture cache in a second.
Depends on D115206
Differential Revision: https://phabricator.services.mozilla.com/D115207
Making room in the texture cache as early as possible reduces the likelihood of allocating extra textures. It will also let us discard unused cached render tasks more aggressively in a folowup patch.
Differential Revision: https://phabricator.services.mozilla.com/D115206
We accidentally were clamping the horizontal stage of the separable blur some
number of samples too early before the end of the row, rather than at the end
of the row.
Differential Revision: https://phabricator.services.mozilla.com/D115309
This renames compatible_type() to can_implicitly_convert_to()
which is a better name. The parameters are renamed to make
it more obvious what's going on. A note is added about
glsl misparsing of float literals and finally, implicit conversion of
float/double to int is removed because that's not supported by glsl.
Differential Revision: https://phabricator.services.mozilla.com/D115247
This adds a span shader that tries to treat the box shadow as a nine-patch
and intersect with the various sectors of it. This allows committing entire
contiguous spans of texture from the source box shadow rather than doing
slower per-fragment processing.
Differential Revision: https://phabricator.services.mozilla.com/D115113
We currently use an EGLSurface from the shared GL context, which is
both not very clean and also likely uses more resources.
Use our just refactored and generalized `WaylandShmBuffer` instead.
Depends on D115083
Differential Revision: https://phabricator.services.mozilla.com/D115139
Previously, these were stored as a SmallVec<2> within each
defined clip template. However, this leads to inefficient
memory usage for most cases.
This is particularly noticeable on youtube.com, which currently
defines a large number of clips.
With this patch, the allocated memory for clips in the display
list drops from ~820 kB to ~450 kB (we should also investigate
and reduce the number of clips defined on this page too).
Differential Revision: https://phabricator.services.mozilla.com/D115039
This gives the RegisterFonts thread more time to complete its work, so that
the main thread doesn't have to wait for it in InitFontList.
In the worst case, where the registration thread still hasn't finished
by the time we call gfxPlatformFontList::PlatformFontList() the first time,
it's still no worse than previously, it just reorders some of the work
that has to be done before we can render any content.
Differential Revision: https://phabricator.services.mozilla.com/D114865
The general contract of a SurfacePoolEntry is that mIOSurface should be
non-null, but this isn't asserted. This patch adds release asserts to ensure
that these surfaces are non-null at the time they are stored and released. It
is one of the possible non-OOM ways that NativeLayerCA::NextSurface could
store a null surface.
Differential Revision: https://phabricator.services.mozilla.com/D113870
On Adreno 505 and 506 devices we encounter frequent crashes when
compiling shaders. We previously attempted to work around this by
ensuring that the source strings were always unique, as we believed it
may be due to buggy caching internally in the driver. This did not
have any effect, however, so this patch reverts the attempted
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D114949
Ensure that we only apply the mix-blend container -> tile cache
optimization in cases where we know the transform on the blend
container is axis-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D114812
This implements a subset of the tag() function on the quartz surface backend;
just enough to support generating links in PDF output. In particular, the
only tag type supported is Link, and we require the link area to be passed
as a list of rects in the 'begin' call; we don't support accumulating all
drawing operations between 'begin' and 'end' into a link area.
Differential Revision: https://phabricator.services.mozilla.com/D114206
This provides a basic Link() API on DrawTarget, intended to generate a link
for a single rectangular area (which will be the rect of a frame corresponding
to a link element).
Differential Revision: https://phabricator.services.mozilla.com/D113774
Clang knows that float + 0.5 is the same as float + 0.5f
so that part shouldn't have any difference except to the reader.
Hopefully ceilf(float) is always identical to ceil(float) too.
Differential Revision: https://phabricator.services.mozilla.com/D114860
This changes to using Option<Matrix> instead of
having an 'invalid' field. This makes sure we check
when we need to and don't have to check otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D114808
This implements a mostly working native backend for Wayland. It can
be enabled via `gfx.webrender.compositor.force-enabled`.
The focus here was to get a basic structure in place while mini-
mising changes in shared code.
Known issues and limitations:
- No readback - this will likely require an internal compositor
again, as Wayland doesn't allow easily allow readback of the
composited image, at least not without asking for permission.
Alternatively, a new Wayland extension could be written for it.
- Frame-call related issues when using a compositor that optimizes
them (e.g. Gnome-Shell). This will be fixed in a follow-up, in
the mean time disabling `widget.wayland.opaque-region.enabled`
and `widget.wayland.vsync.enabled` works around the issues.
- Only works on Weston or very recent versions of Gnome-Shell, see
bug 1699754
Differential Revision: https://phabricator.services.mozilla.com/D111662
Ideally, we wouldn't need to de-duplicate clip ids here, this would
be done at a higher level. However, due to the way we currently
handle redundant stacking context clips, this is a significant
performance win on some pages.
For example, on the youtube.com home page, this drops the size of
the hit-test clip nodes array from ~3800 to ~2200 per scene. This
is still much higher than it should be, but this gives an immediate
performance win while working on the more involved changes to handle
this in a more optimal way.
Differential Revision: https://phabricator.services.mozilla.com/D114705
mCompositor->BeginFrameForWindow() needs to be called for ScreenshotGrabber::MaybeGrabScreenshot() with CompositorD3D11.
Differential Revision: https://phabricator.services.mozilla.com/D114714
The clear region prim don't support complex clip regions (the
complex clip region was being ignored). This has been shipping
like this for many months now, so it seems it's not required.
Differential Revision: https://phabricator.services.mozilla.com/D114563
This makes it easier to understand and will make it easier to not include 'extra' frames (as we're hoping they will coalesce with the original frame on the compositor).
Differential Revision: https://phabricator.services.mozilla.com/D113736
This makes it easier to understand and will make it easier to not include 'extra' frames (as we're hoping they will coalesce with the original frame on the compositor).
Differential Revision: https://phabricator.services.mozilla.com/D113736
When we have a both bottom and top layer, we weren't applying the
transforms in the right order.
Do you know what the right way to test this is?
Differential Revision: https://phabricator.services.mozilla.com/D114629
The code was written assuming the transform origin is the top
of the scrollbar track, but it's actually the layer tree origin.
So far, scaling was only done for thumbs of the root scroll frame
where there is no difference, so no one noticed.
Depends on D114453
Differential Revision: https://phabricator.services.mozilla.com/D114454
Nowadays we often use it for Wayland, which is confusing. Also, it
has a bunch of GTK specific functions, which an alternative X11
implementation would like not have. So a explicit name is probably
deserved.
Depends on D114424
Differential Revision: https://phabricator.services.mozilla.com/D114425
In cases where the overscroll amount is pretty small, the animation's
physics model considers it's finished, which exacly means it's about
to finish, so if we don't call SampleOverscrollAnimation in such cases,
the small amount of overscrolling value remains there, then we try to
create overscroll animations repeatedly even if the overscroll amount
is visually noticeablt.
Differential Revision: https://phabricator.services.mozilla.com/D114445
Timothy Nikkel
Matt Woodrow
Iulian Moraru
sotaro
Glenn Watson
Dzmitry Malyshau
Csoregi Natalia
Robert Mader
Jonathan Kew
Hiroyuki Ikezoe
Nicolas Silva
Lee Salzman
Jeff Muizelaar
Ryan VanderMeulen
Emilio Cobos Alvarez
Sandor Molnar
Andrew Osmond
Brad Werth
Botond Ballo
Jamie Nicol
Bob Owen
Andi-Bogdan Postelnicu
Dorel Luca
Alexandru Michis
Kagami Sascha Rosylight