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
Floating point imprecision can cause the existing test to be unreliable. Just simplify it so it loops around till it overlaps one edge with another. This does a tiny bit more work but will have less chance of exiting earlier than it should.
Differential Revision: https://phabricator.services.mozilla.com/D114236
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
Originally, we would restart the GPU process a fixed number of attempts
based on the layers.gpu-process.max_restarts pref. With this patch, we
now use this pref to control how many "unstable" restarts we allow. A
restart is "stable" if and only if the process uptime exceeds the pref
layers.gpu-process.stable.min-uptime-ts and if the process renders a
total number of frames exceeding the pref
layers.gpu-process.stable.frame-threshold. This allows users to keep the
GPU process for a lot longer if they are encountering infrequent
crashes. Should the user experience the GPU process crashing quickly
and/or without rendering many frames, we will disable it as before after
a few attempts and move into the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D114531
We are seeing lots of crashes on various x86 PowerVR Rogue G6430
devices during the draw calls for GPU cache updates. The crash appears
to only affect x86 devices with this specific GPU. It seems likely
that EXT_color_buffer_float is buggy, so disable usage of it on such
devices. The GPU cache will fall back to using texture uploads instead
of scatter shader updates.
Differential Revision: https://phabricator.services.mozilla.com/D114355
If we're not actually rendering a frame, calling begin_frame/end_frame on the compositor without
adding surfaces can cause us to render a blank frame. Avoid calling begin_frame/end_frame as well
in this situation so that we don't accidentally do this.
Differential Revision: https://phabricator.services.mozilla.com/D114316
Some code in the gradient fast path was expecting that at a certain point we'd either have bailed out of the optimization or the primitive bounds would be tightly clipped. It was possible with a combination of parameters to have a tile repetition that would prevent the tight clipping while being opitmized away after the attempt at clipping. In that case the primitive bounds wouldn't be minimal but we proceed using it as the clip while decomposing gradients into simpler segments.
This patch reorders the optimization code so that clipping is done after sanitizing repetitions, allows the clipping to happen in more cases and as an extra safety uses the intersection of the primitive bounds and clip as the segment clip regardless of whether we achieved a minimal clip earlier.
Differential Revision: https://phabricator.services.mozilla.com/D114255
If a user is able to get D3D11, and Software WebRender hasn't been
forced on (either by the Fission experiment or our pref), then we prefer
D3D11 in late beta and release. This will allow users who start with
D3D11 in the GPU process, to fallback to Software WebRender in the GPU
process.
Differential Revision: https://phabricator.services.mozilla.com/D114286
On Mali-G77 devices we have seen an flickering black bars appear on
pages where we are compositing with an empty dirty region. In such
cases we end up calling eglSetDamageRegion with an empty region,
followed by glClear with an empty scissor rect. Technically calling
eglSetDamageRegion with an empty dirty region is allowed, it just
means you cannot render to the backbuffer at all that frame. The
subsequent glClear call should therefore be fine since an empty
scissor rect is set, but the Mali driver does not like it.
This patch skips calling glClear altogether if the dirty region is
empty, preventing the black bars from appearing.
Differential Revision: https://phabricator.services.mozilla.com/D114346
In bug 1696905 I changed how clear tiles are rendered from multiply blend to opaque, however it breaks window controls on Windows 8 (the only thing that clear tiles are used for). This patch reverts clear tiles to the previous behavior.
I'm not sure how to test this part of the code because it depends on the widget integration code having something to show behind the window.
Differential Revision: https://phabricator.services.mozilla.com/D114327
Fixed the following:
- methods called `to_*` usually take self by reference; consider choosing
a less ambiguous name (clippy::wrong_self_convention)
- an implementation of `From` is preferred since it gives you `Into<_>`
for free where the reverse isn't true (clippy::from_over_into)
- manual implementation of `Option::map` (clippy::manual_map)
- comparing with null is better expressed by the `.is_null()` method
(clippy::cmp_null)
- use of `unwrap_or` followed by a function call (clippy::or_fun_call)
- you don't need to add `&` to all patterns (clippy::match_ref_pats)
- writing `&PathBuf` instead of `&Path` involves a new object where a
slice will do (clippy::ptr_arg)
Locally ignored:
- 6 bindings with single-character names in scope (clippy::many_single_char_names)
Globally ignored:
- this public function dereferences a raw pointer but is not marked
`unsafe` (clippy::not_unsafe_ptr_arg_deref)
- unsafe function's docs miss `# Safety` section (clippy::missing_safety_doc)
Differential Revision: https://phabricator.services.mozilla.com/D114319
This can make scene building up to 10% faster on some pages (such
as the youtube.com front page) that use a large number of clips.
Differential Revision: https://phabricator.services.mozilla.com/D114312
There are two kinds of fixes here.
The first is calling waitToClearOutAnyPotentialScrolls after anything that might cause scrolls to make sure all scrolls are done before we move on in the test (so they don't mess us up later). Calling focus on an element is one thing that causes scrolling that may not be obvious.
The second is using promiseTransformEnd to be sure the zoom to focused input animation is done.
Differential Revision: https://phabricator.services.mozilla.com/D113908
It used to be more convenient to store them in separate arrays but with the new occlusion culling code we don't benefit from it and have to undo it to traverse tiles from front to back.
This is a cleanup patch that should not change the behavior of the code.
Differential Revision: https://phabricator.services.mozilla.com/D113989
This patch introduces a simple culling algorithm that splits compositor tiles into only their visible parts, removing the need for a depth buffer. This reduces the draw-call count as well well as the memory usage and bandwidth associated with the depth buffer.
Differential Revision: https://phabricator.services.mozilla.com/D113532
If an iframe has complex clips, we need to skip including them
in the iframe specific clip applied to the tile cache, as that
path only supports rectangle clips.
Differential Revision: https://phabricator.services.mozilla.com/D114190
This was an old example / proof of concept of directly drawing
to a DirectComposition surface.
We now have the example-compositor/ project that shows how to
integrate with DirectComposition on Windows and Wayland on
Linux, in addition to a shipping implementation in Gecko for
CoreAnimation and DirectComposition.
Differential Revision: https://phabricator.services.mozilla.com/D113052
If we optimize a root level blend container to be a tile cache, we
need to ensure we don't promote compositor surfaces within this slice
as it can result in incorrect blending.
Differential Revision: https://phabricator.services.mozilla.com/D114176
This allows us to factor out parts of the computation into their own
functions without having to pass too many things around as arguments.
Depends on D114159
Differential Revision: https://phabricator.services.mozilla.com/D114160
Matt Woodrow
Hiroyuki Ikezoe
Botond Ballo
Kagami Sascha Rosylight
Robert Mader
Timothy Nikkel
Glenn Watson
Sandor Molnar
Lee Salzman
Andrew Osmond
Jamie Nicol
Nicolas Silva
Jonathan Kew
Mike Hommey
Iulian Moraru
stransky
Jeff Muizelaar