We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.
In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).
Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.
Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.
Changes in the patch:
- Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
- Track nsWindow compositor state by WindowCompositorState
- Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
- Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
- Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.
Differential Revision: https://phabricator.services.mozilla.com/D121650
As it's usually not very useful. I don't know how easily we can add a
reliable test for this, let me know if you come up with an idea to do
that.
Differential Revision: https://phabricator.services.mozilla.com/D122222
On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.
This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.
This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D122221
Move the extra_data to be a specific cache_data separate vec in
the display list payload.
This shouldn't change any functionality, but serves as a proof
of concept for future changes which will introduce several other
separated payload vectors.
Differential Revision: https://phabricator.services.mozilla.com/D121937
This attempts to emulate the behavior of GetRecommendedRenderingMode without
actually calling it. In addition, it allows some Gecko-specific behavior
like overriding the render mode explicitly that allows some simplification
of the decision-making.
Inside GetRecommendedRenderingMode, natural is only allowed if <= 20 size.
This allows us to thus decide mostly based on whether the size is > 20 or
if an explicit mode was specified. In the remaining case where we need
to check a GASP table if available, we defer to the symmetric flag. If
there is no GASP, we assume natural.
Differential Revision: https://phabricator.services.mozilla.com/D122025
Before this patch any item that is wider or taller than 512 pixels goes into its own standalone texture. However we often generate linear gradient tasks with a height of 1 pixels and a width between 512 and 1024. Having them in standalone textures wastes a lot of memory and breaks batches. 1024 pixels fits exactly in the linear color cache texture.
Differential Revision: https://phabricator.services.mozilla.com/D121362
We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.
Depends on D122048
Differential Revision: https://phabricator.services.mozilla.com/D122049
This patch aims to address a worst-case theoretical possibility where the job count might for
some reason get out of sync, causing either the SwComposite thread or the main thread to deadlock
waiting on jobs that may never become available.
To this end, we get rid of the job count tracking entirely, and instead just track whether,
first, the SwComposite thread has completed all the jobs that have been queued for it, and,
second, that the main thread, having completed all jobs that were available, is waiting for
jobs to be available or completed such that the SwComposite thread would need to wake it up.
The main thread does not need to wait if it knows the SwComposite thread completed all jobs,
and the SwComposite thread does not need to signal if it knows the main thread is not waiting.
Otherwise stated, so long as both the main and SwComposite threads know there are no more
available jobs, then there is no way compositing can advance any further, and so compositing
must be finished. This avoids relying on having a job count that is always accurate to track
termination.
Differential Revision: https://phabricator.services.mozilla.com/D121821
It's non WebRender specific, so it will not be a problem on Fission,
additionally it's not used on non WebRender with retained display stuff
either.
Differential Revision: https://phabricator.services.mozilla.com/D121929
This provides settings, which are populated from gfxVars retrieved in the
parent, so that they can be used in all processes.
IDWriteRenderingParams are created lazily, so that we don't try and create them
in processes that have win32k locked down where the API calls will fail.
Differential Revision: https://phabricator.services.mozilla.com/D120597
Note: Sorry in advance that this patch is so big. Unfortunately
splitting it up would create lots of redundant changes.
This should be the last big refactoring for the Wayland compositor
backend for now.
Up until now SurfacePoolWayland was a pool of actual `wl_surface`s,
as before bug 1718569 we had no direct access to `wl_buffer`s when
using EGL. However, the way `SurfacePoolCA` manages native surfaces
is closer to what in Wayland terminology would be a buffer pool:
buffers are heavy-weight and expansive to allocate, while
`wl_surface` objects are cheap to recreate.
So instead of having a pool of surfaces, each of them having its
own pool of buffers, make `wl_surface`s part of tiles and make
`SurfacePoolWayland` manage `wl_buffer`s (in the form of SHM- or
DMABuf buffers). This will allow us to share buffers (especially
depth buffers) more efficiently, reducing VRAM usage and allocation
times.
Apart from that it will also simplify our tile management logic.
Most importantly, we'll need to reorder `wl_surface`s less often and
less complex (no `place_below` the parent surface) and can also drop
reattaching subsurfaces to compositors. Especially the former will
likely decrease CPU time in compositors.
Overall this patch makes `NativeLayerWayland` behave more like
`NativeLayerCA` while taking in lessons learned from
`WindowSurfaceWaylandMB`.
Differential Revision: https://phabricator.services.mozilla.com/D119993
The pending primitives have already been snapped, so this only
has an effect if the shadow offset is fractional. If that's the
case, it's probably reasonable to either (a) not snap at all,
or (b) round the shadow offset earlier.
Differential Revision: https://phabricator.services.mozilla.com/D121500
Currently each VAO owns its own VBO for per-instance array data. Prior
to submitting each draw call that instance buffer is orphaned and a
new one allocated at exactly the right size to contain the batch's
data. This frequent reallocation appears to cause a rendering glitch
on some Adreno 4xx devices, likely due to a bug in the driver's
internal allocation/recycling code. It can also be expensive on some
devices, as the drivers struggle with the overheads of allocating many
small buffers much more than the cost of actually transferring the
data.
This patch makes it so that the VAOs no longer own an instance buffer
each. Instead, they share a pool of buffers. This pool always
allocates buffers large enough to hold the largest batch we
allow. update_vao_instances() now writes data to the pool's current
buffer until that buffer is full, and then either an old one will be
recycled or a new one allocated. After writing to the buffer it must
be bound to the VAO at the correct offset, and then the draw call is
submitted.
By manually managing the buffer lifecycles ourselves we avoid the
glitches on Adreno 4xx, and also improve performance on some devices.
Differential Revision: https://phabricator.services.mozilla.com/D121104
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
We know from testing that the device valid rect itself can sometimes
be empty which produces the symptom that the compositor valid rect
is empty after quantization to i32. So it is sufficient to just check
if that device rect is empty, rather than having to use get_surface_rect
to reproduce the math downstream that produces the compositor valid
rect.
Differential Revision: https://phabricator.services.mozilla.com/D121453
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
The mpsc channel used for reporting glyph rasterization results does not implement
Sync/Send, so the recommended usage pattern is to wrap the channel endpoints in a
Mutex to safeguard them. This, however, turns out to be slow in some cases. Instead,
just always use a crossbeam channel which is thread-safe to begin with and does not
require a Mutex.
Differential Revision: https://phabricator.services.mozilla.com/D121244
Some of the defines are outdated and never actually set, and the
remaining ones can be easily set through existing or easily added
ifdefs.
Differential Revision: https://phabricator.services.mozilla.com/D121064
It has been unsupported since bug 1323303, > 4 years ago.
This removes MOZ_ENABLE_SKIA but keeps USE_SKIA for moz2d for now
Differential Revision: https://phabricator.services.mozilla.com/D120933
If we encounter a device reset in
RenderCompositorD3D11SWGL::TileD3D11::Map, we should fail the call, and
rely upon the device reset checks at the end of a render pass to
recreate our compositor sessions.
Differential Revision: https://phabricator.services.mozilla.com/D121251
Some clang/rustc build setups seem to result in rounding scenarios where the
valid rect, once converted to i32, is somehow empty. This can cause downwind
problems if we actually try to render those tiles. Instead, just cull it before
it becomes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D121144
Although this currently only contains the existing data u8 vec of
serialized bytes, it will allow us to expand this structure in
future to contain other byte arrays.
This will be used for storing other payload information, such as
interned primitive types or data updates.
Differential Revision: https://phabricator.services.mozilla.com/D121160
We have in the past encountered a driver bug on Adreno 3xx devices
where using a flat scalar varying causes the fragment shader output to
be incorrect. See bugs 1630356 and 1705433.
We have now encountered this in cs_border_solid too, due to
vMixColors. As before, packing the varying in to a vector works around
the bug.
Differential Revision: https://phabricator.services.mozilla.com/D121211
Currently each VAO owns its own VBO for per-instance array data. Prior
to submitting each draw call that instance buffer is orphaned and a
new one allocated at exactly the right size to contain the batch's
data. This frequent reallocation appears to cause a rendering glitch
on some Adreno 4xx devices, likely due to a bug in the driver's
internal allocation/recycling code. It can also be expensive on some
devices, as the drivers struggle with the overheads of allocating many
small buffers much more than the cost of actually transferring the
data.
This patch makes it so that the VAOs no longer own an instance buffer
each. Instead, they share a pool of buffers. This pool always
allocates buffers large enough to hold the largest batch we
allow. update_vao_instances() now writes data to the pool's current
buffer until that buffer is full, and then either an old one will be
recycled or a new one allocated. After writing to the buffer it must
be bound to the VAO at the correct offset, and then the draw call is
submitted.
By manually managing the buffer lifecycles ourselves we avoid the
glitches on Adreno 4xx, and also improve performance on some devices.
Differential Revision: https://phabricator.services.mozilla.com/D121104
While running SandboxTest on Windows/Debug setup we can encounter a GPU
process hanging at shutdown. This is due to a destruction race between
GPUParent and VideoBridgeParent, and we end up with one
CompositorThreadHolder reference that is not properly released, making
the GPU process waiting for it.
This change aims at doing the release earlier to prevent such a
destruction race.
Differential Revision: https://phabricator.services.mozilla.com/D121045
This may be another source of failing OOP iframe document print. I will try to
see whether it can be reproducible locally later.
Differential Revision: https://phabricator.services.mozilla.com/D121075
Before this patch the clear tiles were drawn last which meant they would always be drawn on top of all transparent content. It was finde under the assumption that nothing is ever rendered on top of clear tiles, however it turns out to be an issue with the proton window modal darkining which renders some semi-transparent black on top of the whole window (including window controls on windows 8 which use clear tiles). Since the occlusion culling treats clear tiles as opaque they will cut through anything under them regardless of the drawing order, so we can render them before transaprent tiles to get the correct result which is to overwrite what's under the clear tile while still being able to render semi-transparent content on top.
Differential Revision: https://phabricator.services.mozilla.com/D120844
Maybe<T*> is a redundant representation if there is no semantic
difference between Nothing() and Some(nullptr), and just makes
for cumbersome access syntax.
Differential Revision: https://phabricator.services.mozilla.com/D120568
Transforms stored in WebRenderLayerScrollData::mAncestorTransform would
always end up on the topmost hit-testing tree node generated by that
WebRenderLayerScrollData node. That topmost node may not correspond
to the ASR of the transform item(s) which are the source of the
mAncestorTransform. The transform being in the wrong place in the
hit-testing tree can in turn violate APZ's assumptions about different
nodes that scroll together having the same ancestor transform.
To resolve this, this patch stores the transform item's ASR in the
WebRenderLayerScrollData, and applies it to the matching hit-testing
tree node.
Differential Revision: https://phabricator.services.mozilla.com/D120567
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
When changing a reserve/push loop to a resize_with during review
I accidentally removed the clear. This can mean that we end up
with duplicate entries in this pass update arrays.
Differential Revision: https://phabricator.services.mozilla.com/D120690
This seems to be what Chrome does on Windows, and should do the right
thing in other OSes.
On macOS we can do something better and look up the language-dependent
font. That requires further work, but shouldn't probably block this (as
long as system-ui is turned off by default at least).
Differential Revision: https://phabricator.services.mozilla.com/D120714
Alias -apple-system to it, and put it behind a pref for now. This is
pretty boring (read: uncontroversial hopefully) code. The follow-up work
is modifying StaticPresData to look up the fonts using system APIs,
probably. Maybe a bit more work if on macOS they can't be named.
Differential Revision: https://phabricator.services.mozilla.com/D119984
If invalidate_tile() is called not between an enclosing begin_frame()/end_frame(), the tile invalid flag could exist as true in next begin_frame()/end_frame(). It causes the problem. The flag needs to be cleared in begin_frame().
Differential Revision: https://phabricator.services.mozilla.com/D120823
Rayon's collect primitive is somehow establishing recursive dependencies on
waiting for task completion, such that if a lot of glyph jobs are submitted
all at once, this can result in huge recursive stack chains. This simplifies
the glyph job queuing to just send everything immediately over the result
channel, rather than waiting for all jobs in the batch (via collect). We then
rely upon sorting upon receipt to put everything back in a sane order.
Differential Revision: https://phabricator.services.mozilla.com/D120520
Move plane splitter outside the picture state, meaning it doesn't
need to be retained in the picture primitive and passed around
during prepare pass. Another small step to simplifying the prepare
step (interim goal is to remove the recursion here, and then
introduce other prim types, such as a 3d rendering context, that
are able to "contain" child primitives).
Differential Revision: https://phabricator.services.mozilla.com/D120423
In future, we want to persist a lot more of the information about
primitive instances between display lists. This will allow us to
implement a number of optimizations and improvements to the scene
and frame building code (such as reducing per-frame per-prim work
that is typically mostly redundant, supporting prims other than
pictures that can contain child primitives, unifying and optimizing
primitive dependency updates).
As a step towards that, this patch introduces a picture graph which
is very similar to the idea of the render task graph builder. With
this in place, we're able to run picture updates without using
recursion, and ensuring we update pictures in the correct order
that the pass requires. This will allow us to un-tangle a lot of
the existing scene building, visibility, prep and batching pass
complexity, in order to be able to implement the above.
Differential Revision: https://phabricator.services.mozilla.com/D120191
On some Adreno 4xx devices with older drivers we have seen cases where
rendering of masks to alpha targets appears to have no effect. This
results in stale mask data being used for clipping resulting in, for
example, rounded corners appearing as rectangles or strange shapes
rather than solid colours.
This patch performs an unscissored glClear of an alpha target prior to
rendering to it on affected devices, which works around the bug.
Differential Revision: https://phabricator.services.mozilla.com/D120465
It leads to OpenGL errors, as we must initialize a webrender Device in
order to initialize the shaders, and this Device attempts to use
OpenGL commands not supported by the GL context. For example the GL
context may only support GLES 2, hence why we are using SWGL in the
first place.
Differential Revision: https://phabricator.services.mozilla.com/D120356
In the cs_blur fragment shader there is a for loop with a number of
iterations determined by a flat varying. On some old Adreno drivers
this causes severe issues including hangs and crashes. These can be
avoided by clamping the number of iterations to a statically known
value.
Differential Revision: https://phabricator.services.mozilla.com/D120281
Prior to this patch, ToUnknownMatrix() on a Matrix4x4Typed<A, B, double>
would return a Matrix4x4Typed<Unknown, Unknown, float>.
After this patch, it returns a Matrix4x4Typed<Unknown, Unknown, double>.
Differential Revision: https://phabricator.services.mozilla.com/D119696
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
Instead of warning against callers directly accessing the thread message loop,
actuually prevent them from doing so. This is also a preliminary step to
changing the type of the internally-created thread, which will no longer
directly expose its message loop.
Differential Revision: https://phabricator.services.mozilla.com/D119562
This was used when defining scroll layers and also backdrop-filter.
Removing it from the scroll layer API allows removal of the implicit
clip rect that a scroll node previously created (Gecko doesn't use
this). To maintain compatibility with wrench tests, add a flag that
allows a test to specify a clip rect should be created for the scroll
layer (we should remove this from wrench in future and port the tests
to create explicit clip rects as required).
The usage of backdrop-filter was the only remaining place this type
was used, so it's now ported to use the clip-chain API.
This simplifies the scroll layer API and removes an extra clip rect
from each scroll layer instance, as a small performance improvement.
Differential Revision: https://phabricator.services.mozilla.com/D119938
gfx::Factory::CopyDataSourceSurface() was updated so LOCAL_GL_RGBA readFormat and LOCAL_GL_UNSIGNED_BYTE readType is already supported.
Differential Revision: https://phabricator.services.mozilla.com/D118303
This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
Very large gradients are rendered at a lower resolution which is fine for most gradients as they tend to be smooth transitions, but looks bad when there are hard stops.
Differential Revision: https://phabricator.services.mozilla.com/D119628
The tile size edtermines the number of pixels we allocate for the gradinrt pattern, and is eventually clamped to a maximum value. Minimizing the tile size after other transformations avoids some cases where we request more area than we need.
Differential Revision: https://phabricator.services.mozilla.com/D119627
Add MixBlend and ComponentTransfer to the picture composite modes that
unconditionally establish a raster root.
All the known bugs with the raster root code have been fixed, so let's
start incrementally enabling raster roots for more picture modes, and
fix any regressions that come from these before making raster roots
the default for all surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D117954
This becomes possible as a side effect of making sure that the current
buffer content is always completely valid, by blitting from the
previous buffer, analogous to
`NativeLayerCA::HandlePartialUpdate` and
`WindowSurfaceWaylandMB::HandlePartialUpdate`.
Apart from reducing overpaint, this improves correctness is many
situations, avoiding glitches.
Note: the approach here may not be optimal concerning efficiency yet
and improvements are planed after further refactoring.
Depends on D118925
Differential Revision: https://phabricator.services.mozilla.com/D119015
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
If we are re-forwarding a texture that has not been updated then it might still
be read locked. We rely on the read lock for us to know when the Compositor or
Renderer has finished with the texture. So this change copies it to a new
texture, which we can safely read lock.
If the texture is not read locked then we ensure that it is set as updated,
which means we will read lock it as we forward it.
Differential Revision: https://phabricator.services.mozilla.com/D119546
Instead of storing the start time which can be a very large number as f64, keep it in ns as u64 and do the float conversion for the time difference instead.
In addition, the merge function was not behaving synmetrically. It was intended to work as old.merge(new) but we have at least one place in the code where we write it as new.merge(old). In practice takiung the max of the start times when merging two start times does what we want in both direction and makes merging less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D119432
To be more consistent with the rest of the code base and make the
header file easier to read. Also remove an usused function declaration.
Differential Revision: https://phabricator.services.mozilla.com/D119335
Whenever the asr of the deferred transform item differs from the current asr and we are about to enter a new StackingContextHelper (as opposed to just when we enter a transformed frame) flush the deferred transform item, so it's transform doesn't get lost.
This is similar to https://phabricator.services.mozilla.com/D8111. In fact we are extending https://phabricator.services.mozilla.com/D8111 to every time we enter a StackingContextHelper. https://phabricator.services.mozilla.com/D8111 was concerned with solving the case of having two nested transform items with different asrs and making sure we don't lose the outer transform item, here we need to solve the case of an outer transformed item and an inner StackingContextHelper (which is not for a transform) with a different asr and making sure we don't lose the outer transform item.
Note that some of the items I added CreatesStackingContextHelper return true don't always make a new StackingContextHelper. It seemed better to be consistent and I think the only downside is a little less perf because we have to create a few more scrolldata nodes.
Differential Revision: https://phabricator.services.mozilla.com/D118815
Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
Fenix makes use of the default clear color by setting it to a dark
color when the dark theme is enabled to avoid white flashes while
pages are loading. In bug 1663732 we hooked this functionality up to
webrender, however, it was only used by the draw compositor. Now with
software webrender on Android, we sometimes use
RenderCompositorLayersSWGL rather than the draw compositor, and users
are therefore experiencing white flashes during page loads.
This adds a clear_color argument to StartCompositing(), which
RenderCompositorLayersSWGL uses to set the CompositorOGL's clear
color. This patch also makes Renderer::clear_color not an Option
type, as we only ever used it in Some form, and that simplifies the
FFI.
Differential Revision: https://phabricator.services.mozilla.com/D119272
We sometimes see webrender renderer initialization failing due to an
invalid max texture size being reported. The logcat shows that there
is no current GL context, and as a result glGet returns 0 when
querying the max texture size. This occurs after the
AndroidSharedBlitGL context has been destroyed on the renderer thread,
leaving no context as current.
This patch adds a call to MakeCurrent() for the renderer's OpenGL
context prior to renderer initialzation. This means we successfully
query the texture size and avoid the initialization error.
Differential Revision: https://phabricator.services.mozilla.com/D119334
When calling nsDOMWindowUtils::SetResolutionAndScaleTo in a test it's possible to have a layers update that only updates the zoom and nothing else. NotifyLayersUpdated will update the zoom but not the expected gecko metrics when this happens.
Differential Revision: https://phabricator.services.mozilla.com/D119248
When picture cache tiles were changed to be raster roots, this
broke quantizing of glyph sizes based on current scale. Restore
this behavior for high-quality pinch-zoom mode, and also select
the correct fixed scale for low-quality zoom mode.
Differential Revision: https://phabricator.services.mozilla.com/D119145
Previously, the child primitives of off-screen surfaces were not
being atomically treated as a single unit. This meant that the
primitives may be assigned to different sub-slices, under certain
edge case conditions.
As a short term fix, let the picture cache code know when an off
screen surface is being processed during primitive dependency
updates. This ensures that all child primitives within a surface
will be assigned to the same sub-slice.
Differential Revision: https://phabricator.services.mozilla.com/D119052
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
This follows what we're already doing for EGL: a refcounted object
which can own the X connection, where we hold a weak reference from
the library object so that multiple contexts opportunistically share
the display but we close the connection when the last context is
freed/GCed.
In a process where GTK is initialized, we borrow its display instead of
opening a new one, which preserves the existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112195
This is useful for debugging problems on systems such as android
or windows which can sometimes be tricky to get reliable console
output logging.
Differential Revision: https://phabricator.services.mozilla.com/D118772
Copy tiles data when tiles are opaque instead of blending them.
RenderCompositorLayersSWGL always blends tiles as premultiplied tiles. But it could not handle clear tiles and caused Bug 1718497. The problem does not happen with RenderCompositorSWGL. It copies tile data when tile is opaque. Then, RenderCompositorSWGL handles clear tiles correctly.
Differential Revision: https://phabricator.services.mozilla.com/D118953
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Original patch by Erik Kurzinger: D118304
The following is currently not well-defined by the EGL specification:
1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)
After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?
With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.
As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D118743
Now that picture cache tiles are raster roots, their scale is
expressed via the device-pixel scale. This means the calculated
scale can be too small when zoom factor is < 1 and a pinch-zoom
is currently active.
This is not a complete fix, it's an interim improvement until we
implement a proper fix. A complete fix will need to include the
device-pixel scale in the quantization process. However, this will
take some time to get right, since the existing code for selecting
a glyph size is quite complex due to different permutations and
how that code has evolved.
Differential Revision: https://phabricator.services.mozilla.com/D118781
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
Updating raster_scale in post_update can mean that it is
updated one frame too late. This can cause reftest failures
in tests that set the scale factor (without an APZ) and then
capture that frame.
Differential Revision: https://phabricator.services.mozilla.com/D118672
This ensures we get the correct advances for the variation settings that are in use,
not just the font's "default" advances from the hmtx table.
(I'm sad there wasn't a testcase that detected this regression, so added one here.)
Differential Revision: https://phabricator.services.mozilla.com/D118571
Fixes a case where at the end of a pinch-zoom on the Draw compositor
the tiles would be drawn incorrectly (due to the transforms not
being quite right for the local-to-surface case here, which was
affecting the occlusion calculations).
Differential Revision: https://phabricator.services.mozilla.com/D118559
In bug 1717519 we're seeing access violations when writing
to the destination with SWGL. This does some early writes
to try to catch the problem earlier.
Differential Revision: https://phabricator.services.mozilla.com/D118556
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This allows the draw compositor to correctly work with the low
quality pinch-zoom mode.
It also allows handling more external surfaces as compositor
surfaces, by allowing anything with a 2d scale and/or offset.
The y-flip special casing is removed since it's handled by the
general compositor transform support now.
Differential Revision: https://phabricator.services.mozilla.com/D118318
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
Actually, APZ's zoomToRect doens't support position: fixed content. If so,
we use PresShell's scrollIntoView instead to scroll focused content if it
isn't visible.
Differential Revision: https://phabricator.services.mozilla.com/D117728
This removes the last use of DefineClip from Gecko, which will
allow removing and simplifying a lot of the clip handing code
during scene building in WR.
Differential Revision: https://phabricator.services.mozilla.com/D118121
Unlike buffer release callbacks, which can't happen after the
corresponding buffer was destroyed, frame callbacks can apparently
arrive even if the corresponding surface was destroyed.
This kinda makes sense as frame callbacks have independent objects
which actually can get destroyed manually.
Also wait for the lock in the destructor to not unref the surface
below our feet.
Differential Revision: https://phabricator.services.mozilla.com/D118274
This caused e.g. WebGL content to get hidden as it always fell out
of bounds. As a side effect clean up the whole custom transform math.
Differential Revision: https://phabricator.services.mozilla.com/D118288
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
This means that double tapping on an oop iframe "works" in that we don't try (and fail) to zoom the oop iframe. But it also means it is impossible to zoom to some content inside that oop iframe. Instead the best we can do is zoom to the oop iframe itself. This is consistent with what Chrome and Safari currently do. Allowing zooming to content inside an oop iframe would be decently complicated and it doesn't seem worth it. Bug 1715179 is on file for this.
Differential Revision: https://phabricator.services.mozilla.com/D116925
This was introduced in D106246. Most likely it is only necessary
on uncomposited legacy desktops. So on Linux only enable it for X11,
leaving out Wayland.
Removing it makes `RenderCompositorSWGL` behave (more) equally to
`RenderCompositorOGLSWGL`, massively reducing overpaint on certain
websites like testufo.com and improving frame rates on many low-end
devices.
Differential Revision: https://phabricator.services.mozilla.com/D118192
Over time the render target debug view has accidentally started
displaying other texture cache textures too, and then not actually
showing render targets. This makes it show only render target textures
again, as intended.
Differential Revision: https://phabricator.services.mozilla.com/D118187
Instead of drawing updates into the correct spot in the destination
DataSourceSurface we just use it as scratch space and always
draw in the top-left with stride = bpp*width.
We add a dstOffset to the upload functions to support using
a subsurface.
Differential Revision: https://phabricator.services.mozilla.com/D116501
This means that double tapping on an oop iframe "works" in that we don't try (and fail) to zoom the oop iframe. But it also means it is impossible to zoom to some content inside that oop iframe. Instead the best we can do is zoom to the oop iframe itself. This is consistent with what Chrome and Safari currently do. Allowing zooming to content inside an oop iframe would be decently complicated and it doesn't seem worth it. Bug 1715179 is on file for this.
Differential Revision: https://phabricator.services.mozilla.com/D116925
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
This means that double tapping on an oop iframe "works" in that we don't try (and fail) to zoom the oop iframe. But it also means it is impossible to zoom to some content inside that oop iframe. Instead the best we can do is zoom to the oop iframe itself. This is consistent with what Chrome and Safari currently do. Allowing zooming to content inside an oop iframe would be decently complicated and it doesn't seem worth it. Bug 1715179 is on file for this.
Differential Revision: https://phabricator.services.mozilla.com/D116925
Currently we prevent partial picture cache tile invalidation on all
Mali devices to workaround a driver bug. (See bug 1663355 and bug
1691955.) This driver bug affects some Mali-G and Mali-T devices, but
currently we apply the workaround for any Mali GPU.
Mali-400 may or may not be affected by the same driver bug, but since
it uses software webrender we certainly do not need to apply this
workaround.
Allowing partial invalidation should allow for smaller texture uploads.
Differential Revision: https://phabricator.services.mozilla.com/D118017
The values in ScaleOffset keys for the spatial node comparer can
often have very small differences that are causing invalidations but
are not going to affect the rendered content in any noticeable way.
This is _probably_ mostly due to inaccuracies in the way we calculate
the results in get_relative_transform. Instead of using the fast
form parent.inverse().accumulate(child), we could instead traverse
the tree from the parent, accumulating the local transforms. This
would be slightly less efficient but could probably be cached.
There may also be other sources of floating point inaccuracy that
is introduced in the calculations, so for now we will ignore any changes
which have a scale/translation change of < 0.001.
Differential Revision: https://phabricator.services.mozilla.com/D117968
Only a cosmetic change. There is a check during initialization that the constants match the sequential order so little room for getting it wrong.
Differential Revision: https://phabricator.services.mozilla.com/D117702
Also expose the information in the profiler HUD and rename some counters to make it more apparent when specific to the atlases as opposed to other textures managed by the texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D117695
TextureImageEGL doesn't seem to provide any value beyond
BasicTextureImage. It's last usage was bug 814159.
Removing this has the side effect of using BasicTextureImage
for small images instead of always using TilingTextureImage.
Differential Revision: https://phabricator.services.mozilla.com/D117904
Only a cosmetic change. There is a check during initialization that the constants match the sequential order so little room for getting it wrong.
Differential Revision: https://phabricator.services.mozilla.com/D117702
Also expose the information in the profiler HUD and rename some counters to make it more apparent when specific to the atlases as opposed to other textures mamanged by the texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D117695
Ensure that we only invalidate tiles if the surface scale changes
in low-quality pinch zoom mode, since it's irrelevant if the
compositor surface scale changes.
Differential Revision: https://phabricator.services.mozilla.com/D117727
vqmovn_u16 is very different semantically then _mm_packus_epi16. _mm_packus_epi16 treats the input as signed 16-bit integers and narrows to unsigned 8-bit.
vqmovn_u16, however, is an unsigned to unsigned narrow. vqmovun_s16 does what we actually need here, which is to treated the input as signed 16-bit and narrow to unsigned 8-bit.
Differential Revision: https://phabricator.services.mozilla.com/D117705
Only a cosmetic change. There is a check during initialization that the constants match the sequential order so little room for getting it wrong.
Differential Revision: https://phabricator.services.mozilla.com/D117702
Also expose the information in the profiler HUD and rename some counters to make it more apparent when specific to the atlases as opposed to other textures mamanged by the texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D117695
Building on previous patches, this adds a preference to enable
a low quality pinch-zoom mode that reuses cached tiles where
possible.
It doesn't currently redraw at the higher quality scale at the
end of a pinch-zoom, and there are some sampling artifacts in some
cases. However, it should be enough to do some performance testing
on low and devices and see if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D117497
Although blob images let us support very large images, it's easiest
avoid things getting way too big by just reusing our existing limit.
Differential Revision: https://phabricator.services.mozilla.com/D117580
Lee Salzman
Jeff Gilbert
Mike Hommey
Andrew Osmond
stransky
Butkovits Atila
Bob Owen
Emilio Cobos Álvarez
Jamie Nicol
Jonathan Kew
Matt Woodrow
Glenn Watson
Mats Palmgren
Gabriele Svelto
Brindusan Cristian
Nicolas Silva
Timothy Nikkel
Ben Hearsum
Hiroyuki Ikezoe
Jon Bauman
Robert Mader
Marian-Vasile Laza
Dorel Luca
Alexandru Michis
Kashav Madan
Sandor Molnar
Csoregi Natalia
Noemi Erli
Alexandre Lissy
Florian Quèze
Jeff Muizelaar
Botond Ballo
Dzmitry Malyshau
Shravan Narayan
sotaro
Gerald Squelart
Brad Werth
Miko Mynttinen
Markus Stange
Tom Ritter
Jed Davis
Cosmin Sabou
Iulian Moraru
dev
Boris Chiou
Nika Layzell
Makoto Kato
Richal Verma
Andi-Bogdan Postelnicu
Andrew Halberstadt