There appears to be a substantial overhead for trying to wake cold threads
from a thread pool (especially with rayon), so for now let's leave the existing
thread spawning in place, but reduce the stack size for individual threads.
Since these threads only call into SWGL's composite routines and do little else,
there isn't much harm in having a small stack size.
Differential Revision: https://phabricator.services.mozilla.com/D96748
We seem to be spending a significant amount of time inside crossbeam channels
sending jobs across. Sending multiple bands for a given job tends to relock the
channel multiple times when ideally we only want to queue the job once, or lock
the channel once (neither of which we can conveniently do with crossbeam). To
alleviate this, I've implemented a more custom solution with a mutexed VecDeque
and some Condvars.
Differential Revision: https://phabricator.services.mozilla.com/D96520
We don't cache the url, but we do report the "family=" preface, and we respect
the anonymizer flag in the same way that user-fonts are reported.
Differential Revision: https://phabricator.services.mozilla.com/D96643
Whether scrollbar buttons are shown is currently determined by
LookAndFeel values, and these are exposed through system metric media
features. LookAndFeel values are process-wide, but which theme is in
use is document-specific. (It can be the platform's native theme or the
native basic theme, depending on Document::ShouldAvoidNativeTheme.) So
if nsNativeBasicTheme on Linux needs to not support scrollbar buttons,
we can't do this by forcing the LookAndFeel values to be false.
So instead, we skip creating the native anonymous content for the
scrollbar buttons when the non-native theme is in use on Linux. There's
no need to support dynamic changes, since whether the non-native theme
is in use for a given document never changes.
Differential Revision: https://phabricator.services.mozilla.com/D96345
On 10.0 level hardware we only have 14 vecs of varyings allowed.
Reusing v_color_offset for v_flood_color gets us under the limit.
Differential Revision: https://phabricator.services.mozilla.com/D96607
This was an old alternative fling implementation that could be opted
into with the pref apz.android.chrome_fling_physics.enabled=fase.
The pref is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D96508
We set the feature flag when creating the EGL display. This lets us run
WebRender on devices that only support D3D 10.0
Differential Revision: https://phabricator.services.mozilla.com/D96452
GetPlatformDisplay takes a list of EGLAttrib instead of EGLInt. This is needed
if we want to pass EGL_FEATURE_OVERRIDES_ENABLED_ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D96451
This is a preparation of the next part.
Technically, we only need the nsSize's two-argument constructor and
BaseCoord's operator* to be 'constexpr', but for the sake of
completeness, I also make all other BaseCoord's methods 'constexpr'.
Differential Revision: https://phabricator.services.mozilla.com/D96257
This makes the vsync times more consistent.
On a Pixel 2 running Android 11, the callback was called between 1ms and 6ms
after the vsync timestamp in my tests. Having the vsync timestamp slightly in
the past is what the rest of our vsync infrastructure expects.
Differential Revision: https://phabricator.services.mozilla.com/D96279
This backs out part of bug 1656211 which turned out to be insufficient.
The invalidate rendered frame transaction races with the initial frame
rendering of the popup. If it comes in too soon, we will only draw the
frame once, and the frame corruption remains. This patch makes us flush
the rendering pipeline to ensure we get two separate generate frame
events.
Differential Revision: https://phabricator.services.mozilla.com/D96157
This message looks racy and should no longer be required (since
picture caching is always enabled and the composite descriptor
tracks the image generation and dirty rect of external images).
If this _does_ cause a regression, we should fix it by improving
the composite descriptor tracking rather than using a message.
Differential Revision: https://phabricator.services.mozilla.com/D95813
This PR updates wgpu to the latest and changes the way we pass object descriptors to the GPU process.
Instead of trying to convert them between DOM-CPP-IPDL-FFI-Rust, we now do DOM-FFI-Rust
and serialize them by serde into ipc::ByteBuf objects.
Differential Revision: https://phabricator.services.mozilla.com/D94908
Don't take this as indication that I audited all the existing documentation!
I literally just spotted this typo out of the corner of my eye.
Depends on D96194
Differential Revision: https://phabricator.services.mozilla.com/D96195
Mali-Gxx performance really struggles when we make a large number of
glTexSubImage calls, even if the total amount of memory being uploaded
isn't unreasonably large. To work around this, this change makes it so
that we batch many texture updates in to fewer upload calls.
We sort the updates by their target texture format, then use a
guillotine allocator to pack the updates efficiently. Using the
TextureUploader's newly added ability to manually stage texture data,
we arrange the updates' data as they have been packed, then upload the
large texture in a single call. Finally, we blit each update from its
location in the staging texture to its correct location in the texture
cache.
Differential Revision: https://phabricator.services.mozilla.com/D96025
Currently we upload texture data by first splitting the updates based
on their destination texture. Then we iterate through every update for
the texture and calculate the total required size, then allocate and
map a PBO large enough to contain the updates. Finally we fill the PBO
with the data and submit the uploads, before moving on to the next
texture. This results in a lot of allocating and mapping PBOs of
highly variable sizes, and also requires an extra iteration of the
updates to calculate the required size.
This change makes it so that we allocate fixed size PBOs. We fill the
PBOs with as many updates as they have room for, then start filling a
new one. Furthermore, we recycle the PBOs to avoid having to
reallocate them, and if possible we persistently map them too.
The TextureUploader struct can now be used to upload to more than one
texture, ensuring buffers are filled more efficiently. It is also now
possible to manually stage some data in the PBO to be uploaded, in
case the client requires more fine-grained control over the layout of
the data.
If a single upload is too large to fit within the fixed-size PBO, then
we allocate a single-use larger PBO for the upload. As before, on Mac
we unfortunately must use a separate PBO for each individual upload,
so we also allocate single-use custom-sized PBOs in that case.
Differential Revision: https://phabricator.services.mozilla.com/D96024
This PR updates wgpu to the latest and changes the way we pass object descriptors to the GPU process.
Instead of trying to convert them between DOM-CPP-IPDL-FFI-Rust, we now do DOM-FFI-Rust
and serialize them by serde into ipc::ByteBuf objects.
Differential Revision: https://phabricator.services.mozilla.com/D94908