This seems to make a big difference when running tests with WARP.
e.g. Assertion failure: frameInfo.mDocFramesSeen == frameInfo.mDocFramesTotal,
at z:/build/build/src/gfx/webrender_bindings/RenderThread.cpp:303
and various other browser chrome test failures.
The original problem that added this flag only impacted AMD hardware as I
recall and we are unlikely to ever be running on WARP in production anyways.
When WARP is forced we also don't disable INTERNAL_THREADING_OPTIMIZATIONS.
Differential Revision: https://phabricator.services.mozilla.com/D42214
--HG--
extra : moz-landing-system : lando
There's no other caller that sets ReadBuffer to anything else, and GL_BACK is
the default for default framebuffers. Furthermore, this call triggers
GL_INVALID_OPERATION errors when called on a non-default framebuffer.
Differential Revision: https://phabricator.services.mozilla.com/D40551
--HG--
extra : moz-landing-system : lando
NativeLayerRoot and NativeLayer allow building up a flat layer "tree" of sibling
layers. They're created and manipulated with a synchronous-looking API, but any
changes will only be applied to the underlying native layers when ApplyChanges()
is called. This ensures that the modifications can be limited to run within a
CoreAnimation transaction, and on a thread of the caller's choosing.
In the near future I'm planning to have LayerManagerComposite create these
layers. That's the reason for the pseudo-abstracted cross-platform C++ API:
LayerManagerComposite can create and place the layers, and any painting into the
layer surfaces will happen in the compositor implementations with platform-specific
code.
For now, the CoreAnimation implementation is the only implementation. I think
the current API will let us use the same infrastructure for DirectComposite
layers on Windows, but we'll likely need to make some API modifications once we
attempt that.
The classes are threadsafe; their methods can be called on any thread and the
caller is responsible for sufficient synchronization. In reality, there are only
two threads that would have a reason to use these layers: The compositor thread
and the main thread. The main thread creates and destroys the NativeLayerRootCA,
and sometimes it calls ApplyChanges, e.g. during window resizes. It also calls
SetBackingScale. All other methods are usually only called on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D26407
--HG--
extra : moz-landing-system : lando
This removes the assumption that there is a default framebuffer to read from,
in order to prepare for a world in which all rendering goes into non-default
framebuffers.
The current render target's framebuffer is already bound when this function is
called.
Differential Revision: https://phabricator.services.mozilla.com/D40513
--HG--
extra : moz-landing-system : lando
In the past, mFullWindowRenderTarget was updated in EndFrame, so the captured
screenshots (which were captured before EndFrame) were always one frame behind.
This affected both profiler screenshots and window recording screenshots.
This also fixes a bug with the destination offset in the call to
mFullWindowRenderTarget->mDrawTarget->CopySurface(): In the case where mTarget
was non-null, those calls would use mTargetBounds.TopLeft() as the destination
offset, which is very much unrelated to anything in mFullWindowRenderTarget.
Now the destination offset for mFullWindowRenderTarget is always zero -
mFullWindowRenderTarget->mDrawTarget's device space is the same as window space.
This patch also moves the creation of mFullWindowRenderTarget down to where we
have mRenderTarget->mDrawTarget, so that we can create a DrawTarget of a type
that can efficiently copy from mRenderTarget->mDrawTarget. I think this is
important on Windows where mRenderTarget->mDrawTarget will be the Cairo/pixman
re-wrapped DrawTarget and mDrawTarget is some kind of Windows/GDI DrawTarget.
Depends on D41612
Differential Revision: https://phabricator.services.mozilla.com/D41613
--HG--
extra : moz-landing-system : lando
These areas only need to be cleared in rt->mDrawTarget. Once the invalid area gets
copied over to mFullWindowRenderTarget, any cleared pixels will be copied over and
clear those pixels in mFullWindowRenderTarget.
This clear wasn't only necessary, it also sometimes cleared to much, because the
clip to the invalid region that the caller sets does not apply to this DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D41612
--HG--
extra : moz-landing-system : lando
The commit also adds a missing StaticPrefs_dom.h include for APZEventState.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D41915
--HG--
extra : moz-landing-system : lando
Since the filtered-backdrop is 1:1 with the backdrop, we don't want any snap offsets to shift the contents
Differential Revision: https://phabricator.services.mozilla.com/D42042
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
These were used for creating accelerated CGContexts that render to an IOSurface.
We only used those experimentally on Nightly for a while but turned that option
off because of crashes. And in the meantime, DrawTargetCG has been removed
entirely. So we'll probably never use these functions again.
Differential Revision: https://phabricator.services.mozilla.com/D41809
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
As a result of the expansion, position:fixed elements are attached to the
expanded layout viewport.
The expanded value is used behind a pref which is enabled by default on nightly
initially, and the pref will be fliped in bug 1571599 on other channels.
scrollbars-in-landscape-content.html still fails since the vertical overlay
scrollbar doesn't appear since we are not yet using the expanded value during
reflow to tell whether we need overlay scrollbars or not. This will be fixed
by the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D40771
--HG--
extra : moz-landing-system : lando
Fixes an issue when backdrop-filter is used many time on a page where we would
spend a large amount of time reevaluating render tasks when assigning task depths.
Differential Revision: https://phabricator.services.mozilla.com/D41252
--HG--
extra : moz-landing-system : lando
The user pref already takes precedent over the environment so there's no need
to run the code later. Further, we assert that environment values haven't been
set.
Differential Revision: https://phabricator.services.mozilla.com/D41836
--HG--
extra : moz-landing-system : lando
When Windows version is mort than 1903 and GPU is intel GPU, it could cause flickering with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. See Bug 1556634. As a short term workaround, use DXGI_ALPHA_MODE_PREMULTIPLIED instead of DXGI_ALPHA_MODE_IGNORE at SwapChain.
Differential Revision: https://phabricator.services.mozilla.com/D41713
--HG--
extra : moz-landing-system : lando
This makes us use the actual adapter description instead of a null one.
This fixes the problem of a mismatch being detected in ContentAdapterIsParentAdapter which
is using D3D11Checks::GetDxgiDesc to determine the adapter.
Differential Revision: https://phabricator.services.mozilla.com/D41804
--HG--
extra : moz-landing-system : lando
With this patch, tiles that are covered only by the opaque backdrop
primitive are detected and noted as solid colors.
Solid color tiles save memory and performance, because:
- No texture slice is allocated as a render target for them.
- No need to rasterize this tile.
- Drawing the tile is done with the faster rectangle shader.
This already saves performance and GPU memory on quite a few
real world sites (esp. when running at 4k). However, the main
benefit of this will be once we enable picture caching on
multiple content slices and the UI layer. When this occurs, it's
important to avoid allocating tile buffers for all the solid
rectangle tiles that the UI layer typically contains.
Differential Revision: https://phabricator.services.mozilla.com/D41342
--HG--
extra : moz-landing-system : lando
Frames captured by the composition recorder on non-ANGLE configurations were
previously written upside down to disk. We now flip them right side up when
mapping them into memory.
Differential Revision: https://phabricator.services.mozilla.com/D40113
--HG--
extra : moz-landing-system : lando
Also includes some documentation gardening for TextDrawTarget on what we don't support.
Differential Revision: https://phabricator.services.mozilla.com/D41272
--HG--
extra : moz-landing-system : lando
This is a medium-size follow-up to D21965.
Refactors the use of swizzling by the texture cache. Adds a device
capability flag that is checked at run-time. Also makes the texture
cache to communicate with the texture uploader if there is a format
conversion needed, which fixes the case on platforms that don't
support swizzling.
Differential Revision: https://phabricator.services.mozilla.com/D41446
--HG--
extra : moz-landing-system : lando
We only use the result of this calculation for composites to the actual window
(and stash it for later if this composite is to an external target), so
mTargetBounds is always unrelated.
Differential Revision: https://phabricator.services.mozilla.com/D40871
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
This change adds a new export, SendUIMessageToVRWindow, from vrhost.dll
that allows the caller to forward a subset of UI messages to the VR
window in Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D40828
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
Functions available only in Nightlies should not be exported outside of Nightly
builds. This change splits the exports into 2 def files (since the preprocessor
is not available for def file).
Differential Revision: https://phabricator.services.mozilla.com/D40653
--HG--
extra : moz-landing-system : lando
When adding planes to the plane splitter, we supply a world clip
rect to the polygon clipper. Generally this is used to help with
float accuracy issues, but it also clips polygons to the visible
region.
The previous code supplied the visible world rect, but this is
not always correct. When drawing picture cache tiles, we may
be rendering to a tile that is partially off-screen. In this case
we need to pass the combined world dirty rect, which is inflated
to include the off-screen tile parts that are being drawn. This
ensures that preserve-3d items are correctly clipped to the tile
boundaries rather than the currently visible screen rect.
Differential Revision: https://phabricator.services.mozilla.com/D41111
--HG--
extra : moz-landing-system : lando
Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
In order to support multiple API's (WebVR + WebXR) being enabled simultaneously, a new class, gfx::VRManagerEventObserver, implements a pure virtual interface to be shared by both the WebVR and WebXR observers of XR device related events.
Differential Revision: https://phabricator.services.mozilla.com/D39985
--HG--
extra : moz-landing-system : lando
Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
have texture cache to manage potentially multiple array textures of each type.
Differential Revision: https://phabricator.services.mozilla.com/D39912
--HG--
extra : moz-landing-system : lando
We already skip painting hit test items. We can do even better
by not including them in the recording at all.
Differential Revision: https://phabricator.services.mozilla.com/D40859
--HG--
extra : moz-landing-system : lando
There's another call inside Render() but that's usually too late.
Depends on D40558
Differential Revision: https://phabricator.services.mozilla.com/D40559
--HG--
extra : moz-landing-system : lando
An alternative approach, which I would have preferred, would be to keep the old
mClonedLayerTreeProperties around, so that future frames can compare to the
last non-aborted mClonedLayerTreeProperties. However, that doesn't work in the
current world because mClonedLayerTreeProperties->ComputeDifferences has side-
effects.
Differential Revision: https://phabricator.services.mozilla.com/D40558
--HG--
extra : moz-landing-system : lando
This makes it clear that these belong to a single frame and makes some assumptions explicit.
For example, in the old code, mDocFrameCounts.size() was the same as mPendingFrames.size()
when a pending frame was added, but then the sizes differed during rendering because a frame's
mDocFrameCount would be popped at the beginning of rendering while mPendingFrames would be
popped at the end of rendering.
This modification also makes some clearing of values unnecessary. A new frame always starts out
with cleared values for mDocFramesSeen and mFrameNeedsRender.
This patch also combines the two locks in HandleFrameOneDoc.
Depends on D40373
Differential Revision: https://phabricator.services.mozilla.com/D40374
--HG--
extra : moz-landing-system : lando
The only place that increments mRenderingCount, HandleFrameOneDoc, also synchronously calls FrameRenderingComplete
at the end of the function, which decrements mRenderingCount again. So it can never grow beyond 1.
Depends on D40372
Differential Revision: https://phabricator.services.mozilla.com/D40373
--HG--
extra : moz-landing-system : lando
IncRenderingFrame only had one caller. Inlining it into HandleFrame makes it clearer
how the values in mWindowInfos are mutated and in what order calls happen.
This also renames HandleFrame to HandleFrameOneDoc, because we're expecting one call
per document before we actually trigger the render.
Depends on D40370
Differential Revision: https://phabricator.services.mozilla.com/D40371
--HG--
extra : moz-landing-system : lando
When PersistentBufferProviderShared::ClearCachedResources() is called, PersistentBufferProviderShared keeps front TextureClient. But TextureHost's read lock might be released by host side. Then TextureClient's read lock could not be used for checking if the TexutreClient is used by host side.
Differential Revision: https://phabricator.services.mozilla.com/D40440
--HG--
extra : moz-landing-system : lando
This change creates the new export CreateVRWindow from vrhost.dll. This API
results in spawning a new Firefox window with the Firefox Reality 2D UI and
returns data needed for the host to interact with it. VRShMem is used to pass
data across process boundaries during this bootstrap process.
Additional tests are added to vrhost to be later converted to unittests.
Differential Revision: https://phabricator.services.mozilla.com/D40236
--HG--
rename : gfx/vr/vrhost/vrhost.cpp => gfx/vr/vrhost/vrhosttest.cpp
extra : moz-landing-system : lando
In order to support the WebXR implementation, VRDisplayState is being extended to enumerate the type of sessions a device supports (Inline, Immersive-VR, or Immersive-AR) and to report if the blend mode for AR would be additive or alpha blended).
Differential Revision: https://phabricator.services.mozilla.com/D39916
--HG--
extra : moz-landing-system : lando
those unwrap_or are mostly seen during the batching, where we should asssume that
the primitives are not clipped out and just unwrap() accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39940
--HG--
extra : moz-landing-system : lando
Refactors get_clip_result_complex to cover ClipOut cases for rectangles as well
as Clip for non-repeated images.
Differential Revision: https://phabricator.services.mozilla.com/D40094
--HG--
extra : moz-landing-system : lando
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
--HG--
extra : moz-landing-system : lando
Now that there is only ever a single handle to the `CompositionRecorder`, it no
longer needs to be ref-counted. And since the `WebRenderCompositionRecorder` is
owned exclusively by the `RenderThread`, it no longer needs a mutex. All the
code that resulted from having handles to the `WebRenderCompositionRecorder` on
two different threads is now no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39791
--HG--
extra : moz-landing-system : lando
Since we are not writing frames to disk from the `CompositorBridgeParent` in
the WebRender case, we do not actually need a handle to the
`(WebRender)CompositionRecorder` there. Instead, the `HostLayerManager` and
`RenderThread` can maintain exclusive handles to these objects. This will allow
us to use unique pointers for these objects and delete code in a follow up
patch.
Differential Revision: https://phabricator.services.mozilla.com/D39790
--HG--
extra : moz-landing-system : lando
On macOS, if we try to write the collected frames from the
`CompositorBridgeParent` we will not have an active GL context, resulting in a
crash. Writing the frames from the `RenderThread` solves this problem.
Differential Revision: https://phabricator.services.mozilla.com/D39789
--HG--
extra : moz-landing-system : lando
Instead of blindly attempting to write frames to disk, we now ensure that the
`CompositionRecorder` exists. In the case where we have not allocated one,
calling `windowUtils.setCompositionRecording(false)` will instead print an
error message to the browser console.
In addition, attempting to call `windowUtils.setCompositionRecording(true)`
while a `CompositionRecorder` exists will also result in an error message.
Differential Revision: https://phabricator.services.mozilla.com/D39584
--HG--
extra : moz-landing-system : lando
This change was unintentional and may be responsible for the performance regression seen in
bug 1570256.
Differential Revision: https://phabricator.services.mozilla.com/D40085
--HG--
extra : moz-landing-system : lando
ScaledFontFreeType::GetWRFontInstanceOptions() was neglecting to set
the FontInstanceFlags::EMBEDDED_BITMAPS flag. This was causing us to
always take the non-bitmap path when rasterizing the glyph, which
fails on android because emoji fonts are bitmap only. Setting this
flag causes glyphs to be rendered correctly on android webrender.
Differential Revision: https://phabricator.services.mozilla.com/D40062
--HG--
extra : moz-landing-system : lando
Allow the swizzle to be configurable with a texture binding. This is still experimental and needs to be tested well on all platforms.
Basic approach is the following:
- WR device figures out how it can use BGRA and makes the texture cache format configurable at run-time. It tries to make the uploads to the shared texture cache pages to be done without any driver conversions, and without extra memory allocated.
- it also reports the preferred input format for the images, which may be different from the texture cache format
- if WR texture cache is asked to allocate a shared texture with a different (swizzled) format from the preferred, it associates the cache entry with a swizzle
- the swizzle becomes a part of the `SourceTexture`, which affects batch splitting
- when a texture reaches binding by GL device, it checks whether the current swizzle on this texture doesn't match the given one, and configures the texture sampling accordingly
- we can't use blits with swizzling, so when that needs to happen we use `cs_copy` path, which is now mostly rewritten
The idea is that Gecko would ask WR for the preferred format and configure its image decoding to produce image data that doesn't require any swizzling.
The PR changes existing texture upload (and batching) paths. On Linux, if texture storage is available, we now use it and provide the data as RGBA, assuming no conversion by the driver. The swizzling kicks in when we sample this data in the shader. On Windows/Angle we use BGRA as an internal format for texture cache and expect Gecko to provide BGRA data, this should be unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D21965
--HG--
extra : moz-landing-system : lando
Call VRManager::StartFrame directly instead of using a PostTask on Android.
Differential Revision: https://phabricator.services.mozilla.com/D39691
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
WebRender handling of position:sticky is buggy in the presence of zooming.
The fix for bug 1563717 exposes this bug in pinch-zoom-position-sticky.html.
Differential Revision: https://phabricator.services.mozilla.com/D39574
--HG--
extra : moz-landing-system : lando
The clip rect is derived from the composition bounds, which is in units that
are outside the resolution, but it's applied to the ScrollFrame item which is
inside the resolution.
Differential Revision: https://phabricator.services.mozilla.com/D37939
--HG--
extra : moz-landing-system : lando
Some initialization handlings of ClientLayerManager exists in nsBaseWidget::CreateCompositor(). It is not good. Move them to ClientLayerManager::Initialize().
Differential Revision: https://phabricator.services.mozilla.com/D39476
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
The glReadPixels call for capturing profiler screenshots is very slow
on Adreno devices. Similarly to bug 1498732, this is because the
stride of the data being transferred is not a multiple of 256, so the
driver is taking the synchronous path instead of reading in to a PBO
asynchronously.
This solves this problem by increasing the width of the area we read
so that we hit the fast path. To do this we must ensure that the PBO
and the final scale-down texture are large enough to include the extra
pixels in each row. As the required size of the PBO or texture may now
change, for example after a screen rotation, we now handle deleting
and recreating them when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39189
--HG--
extra : moz-landing-system : lando
StaticPrefs.h will be removed two commits from now, so update these comments.
The patch removes the comment above SetUsesContainerScrolling() because it's
wrong -- it did use static prefs when introduced by bug 1181832 but then
stopped using static prefs in bug 1470504 -- and makes it inlinable.
Differential Revision: https://phabricator.services.mozilla.com/D39133
--HG--
extra : moz-landing-system : lando
These files exist because they were the proof-of-concept first step for
splitting the static prefs header files. Now that those header files can be
generated from a script, we need to move the `accessibility.*` prefs into the
YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D39132
--HG--
extra : moz-landing-system : lando
For retained display lists it needs to be a weak frame region to areas get removed for modified frames and the rest stick around.
Each display item can contribute an opaque region but WeakFrameRegion can only track one rect per frame. It turns out that we only return rects from GetOpaqueRegion except in one hit testing case.
This still means more than one display item per frame could be contributing to the opaque region, we would miss the second and further rects in that case.
Differential Revision: https://phabricator.services.mozilla.com/D38589
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
GPUVideoTextureHost::NumSubTextures() returns 0 when wrapped TextureHost does not exist. In this case, we do not have a content of GPUVideoTextureHost for WR render. And EnsureWrappedTextureHost() calling is added in GPUVideoTextureHost::NumSubTextures(), since GPUVideoTextureHost is not explicit about when a wrapped TextureHost is created.
Differential Revision: https://phabricator.services.mozilla.com/D39137
--HG--
extra : moz-landing-system : lando
looks like a typo that got unnoticed? I wonder how our alpha saved tasks work today :)
Differential Revision: https://phabricator.services.mozilla.com/D39021
--HG--
extra : moz-landing-system : lando
`sGfxLogLevel` is a global variable whose value mirrors the value of the
"gfx.logging.level" pref in the prefs table, and is kept up to date by a
prefs callback.
But "gfx.logging.level" is a static pref that already has a mirror variable,
accessible via `StaticPrefs::gfx_logging_level()`.
So we can use the latter and remove the former, and this patch does that. The
patch also removes a sentence in a comment that refers to special treatment of
LOG_DEBUG and LOG_DEBUG_PRLOG, because that sentence appears to be referring to
something (another comment?) that is no longer present.
Differential Revision: https://phabricator.services.mozilla.com/D35625
--HG--
extra : moz-landing-system : lando
The RemoveShaderCacheFromDiskIfNecessary() needs to be called after WebRenderConfig initialization.
Differential Revision: https://phabricator.services.mozilla.com/D38978
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This patch fixes a couple of picture caching issues that could
cause more invalidations than required. Specifically:
* Ensure the viewport rect is included in child surfaces, so
that redundant clips are filtered out correctly.
* Use epsilon comparisons where appropriate for tile descriptor
comparisons, to avoid invalidations due to float inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D38455
--HG--
extra : moz-landing-system : lando
The code to batch preserve-3d elements was incorrectly using the
bounds and visibility mask from the parent element. This could
result in batching bugs in some cases, which were showing up as
draw order issues.
Differential Revision: https://phabricator.services.mozilla.com/D38834
--HG--
extra : moz-landing-system : lando
This is done my adding two new canvas RecordedEvents, which add and remove the
SourceSurfaceCanvasRecording as an alias to the SourceSurfaces that they wrap.
Differential Revision: https://phabricator.services.mozilla.com/D37089
--HG--
extra : moz-landing-system : lando
This also fixes the CanvasParent destruction on channel close and error,
which was broken due to IPDL changes between rebases.
Differential Revision: https://phabricator.services.mozilla.com/D37088
--HG--
extra : moz-landing-system : lando
A few potential error cases were being unwrapped, resulting in a very
small number of crashes. These errors can be safely ignored as the
program cache is non-critical, so this change makes us log the error
and continue rather than panicking.
Differential Revision: https://phabricator.services.mozilla.com/D38650
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This better distinguishes it from the pref name part of the getter, which uses
snake case.
Differential Revision: https://phabricator.services.mozilla.com/D38603
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
Minor things to ease the transition to StaticPrefList.yaml.
- Rename apz_touch_drag_enabled() to the correct apz_drag_touch_enabled(), and
media_mwf_low_latency_force_disabled() to the correct
media_wmf_low_latency_force_disabled().
- Change some trailing C-style comments to C++-style comments. This makes life
easier for the script I wrote to convert StaticPrefList.h to
StaticPrefList.yaml, which will be used for the next patch.
- Avoid comments on #define lines, because they aren't handled in the YAML
input.
- Convert a multi-line `#if` condition to a single line, because
Preprocessor.py doesn't handle multi-line conditions.
- Remove one unnecessary `#undef PREF_VALUE` directive.
- Move intl.charset.detector.iso2022jp.allowed to the correct section, so the
YAML processing script won't complain.
- Change an `int` pref to `int32_t`, again so the YAML processing script won't
complain.
- Change OS_OPENBSD to XP_OPENBSD, because the former isn't defined for
preprocessor.py. (It's also only defined in C/C++ when chromium-config.h is
included, which isn't always the case.)
Differential Revision: https://phabricator.services.mozilla.com/D37815
--HG--
extra : moz-landing-system : lando
Since Bug 1531898 fix, fix of Bug 1552734 is not necessary anymore. The backout reduces memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D38257
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26412
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26411
--HG--
extra : moz-landing-system : lando
RenderTargetOGL::Bind on mWindowRenderTarget needs to bind the default framebuffer, not framebuffer 0.
Differential Revision: https://phabricator.services.mozilla.com/D26405
--HG--
extra : moz-landing-system : lando
Connor Brewster
Nicholas Nethercote
Jeff Muizelaar
Markus Stange
Imanol Fernandez
Gabriele Svelto
Jed Davis
Bogdan Tara
arthur.iakab
Nathan Froyd
Matt Woodrow
Jeff Gilbert
Coroiu Cristina
Hiroyuki Ikezoe
sotaro
Botond Ballo
Brad Werth
John Dai
Sylvestre Ledru
Glenn Watson
Bastien Orivel
Kris Taeleman
Barret Rennie
Jonathan Kew
Alexis Beingessner
Dzmitry Malyshau
Noemi Erli
thomasmo
Nicolas Silva
Nika Layzell
L. David Baron
Narcis Beleuzu
Kearwood "Kip" Gilbert
Tom Schuster
Charlie Marlow
Bob Owen
Cosmin Sabou
Razvan Maries
Lee Salzman
Ciure Andrei
Timothy Nikkel
Jamie Nicol
Joel Maher
shindli
Jean-Yves Avenard
Doug Thayer
Martin Stransky
Andreea Pavel
Mihai Alexandru Michis
Csoregi Natalia
Kartikaya Gupta
David Walsh
Sebastian Hengst