We always expect integer values here, even with fractional scaling,
and if floating point errors cause `bufferClip.x` or `bufferClip.y` to
fall slightly below `0`, this will cause a protocol error.
We can savely avoid this by simply rounding the rect.
Differential Revision: https://phabricator.services.mozilla.com/D123289
Submitting invalid values to the Wayland compositor will trigger a
protocol error, which in turn will trigger an unhandled crash.
In order to create crash reports in such cases, assert on valid
values in such cases.
In the long run we can replace this with a general Wayland protocol
error handler.
Differential Revision: https://phabricator.services.mozilla.com/D123286
Intel BayTrail devices claim to support GL_EXT_texture_format_BGRA8888
as well as GL_EXT_texture_storage, which means we should be able to
use glTexStorage along with a BGRA internal format. However, doing so
does not work, resulting in black squares being rendered rather than
images.
Instead, use RGBA as the internal format and rely on texture swizzling
during sampling.
Differential Revision: https://phabricator.services.mozilla.com/D123246
What we want to assert is that, apart from a couple of edge cases,
aAncestorTransformId is represented in mScrollIds.
The previous approach assumed that mScrollIds was populated entirely
in the loop above, but in fact it can also be populated via
AppendScrollMetadata().
Differential Revision: https://phabricator.services.mozilla.com/D123036
The test function in helper_touch_action_regions.html needs to run as a
generator function, which means it doesn't work with async/await manners, so
once after we make some utility functions as async, it won't work as expected.
To avoid it, getting the scroller position in the screen coords part needs to
be split out from the generator since the part will be async in the next commit,
and nsIDOMWindowUtils.sendNativeTouchPoint needs to be used directly instead of
using synthesizeNativeTouch since synthesizeNativeTouch will also be async.
Differential Revision: https://phabricator.services.mozilla.com/D122558
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
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
To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
Before this patch the embedded profiler would show the last avg/max values for a profile counter if it hasn't had samples for a long time. After this patch the counter shows 0 if there was no sample.
For example when no glyphs are rasterized there are no 'Rasterized glyphs' samples. If no glyphs are rasterized for multiple seconds then we are currently still showing the average and max number of rasterized glyphs from seconds ago which makes it look like we are constantly rasterizing glyphs. With this patch the counter goes back to zero after half a second of not rasterizing glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D122263
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
Andi-Bogdan Postelnicu
Robert Mader
Alexandru Michis
Hiroyuki Ikezoe
Csoregi Natalia
Jeff Gilbert
Butkovits Atila
Michelle Goossens
Jamie Nicol
Jeff Muizelaar
Cosmin Sabou
Matt Woodrow
Botond Ballo
Dzmitry Malyshau
Brindusan Cristian
Timothy Nikkel
Narcis Beleuzu
Jon Bauman
Jonathan Kew
Glenn Watson
Markus Stange
Andrew Osmond
Iulian Moraru
Nicolas Silva
Lee Salzman
Mike Hommey
stransky
Bob Owen
Emilio Cobos Álvarez
Mats Palmgren
Gabriele Svelto
Ben Hearsum
Marian-Vasile Laza
Dorel Luca
Kashav Madan
Sandor Molnar
Noemi Erli
Alexandre Lissy
Florian Quèze
Shravan Narayan
sotaro
Gerald Squelart
Brad Werth
Miko Mynttinen
Tom Ritter
Jed Davis