test_abort_smooth_scroll_by_instant_scroll.html in this comment is a test case
to make sure this change doesn't regress a case where a smoothe scrolling run
by an APZC is replaced by an instant scroll operation by script.
Some other mochitests for this change are in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D129594
Both window_bug1369072.html and browser_scroll.js have a pattern something like;
1) Call synthesizeKey to scroll an element
2) Wait a scroll event
3) Test something
4) (Re)set the scroll position to (0, 0) by calling Element.scrollTop and
Element.scrollLeft or scrollTo.
With the new transmogrification the step 4) will not reset the scroll position
if there's an on-going scroll animation in APZ triggered by the synthesizeKey.
To avoid the situation where there's an on-going animation at the step 4), we
destroy the corresponding scrollable frame and reconstruct it so that it
clobbers the animation.
Differential Revision: https://phabricator.services.mozilla.com/D130852
Without specifying the value, even if synthesizeNativeWheel causes wheel inputs,
it will be converted to an instant scroll rather than smooth. In fact on Mac
mouse wheeling causes this type of events that is that the events'
hasPreciseScrollingDeltas flag is false.
Differential Revision: https://phabricator.services.mozilla.com/D129591
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
sk_sp requires its type to be defined at the point of sk_sp declaration.
Just use RefPtr instead which does not have this limitation so we can move
some Skia includes out of the Moz2D headers.
Differential Revision: https://phabricator.services.mozilla.com/D130387
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
sk_sp requires its type to be defined at the point of sk_sp declaration.
Just use RefPtr instead which does not have this limitation so we can move
some Skia includes out of the Moz2D headers.
Differential Revision: https://phabricator.services.mozilla.com/D130387
WR tries to normalize Mac FontInstances so that regardless of the font color
we only need to generate one version of the glyph in the cache. This strategy
backfires for fonts with color glyphs that are nominally supposed to ignore
the font color, but may choose to opt-in to the font color per-glyph based
on table data.
This determination is problematic to do in WR itself, but Gecko knows whether
a font has color glyphs ahead of time. So we let Gecko pass this data into
ScaledFonts which can then transmit the knowledge of whether the font has
color glyphs to the WR Mac font backend, which will then take appropriate
action.
Differential Revision: https://phabricator.services.mozilla.com/D130819
WR tries to normalize Mac FontInstances so that regardless of the font color
we only need to generate one version of the glyph in the cache. This strategy
backfires for fonts with color glyphs that are nominally supposed to ignore
the font color, but may choose to opt-in to the font color per-glyph based
on table data.
This determination is problematic to do in WR itself, but Gecko knows whether
a font has color glyphs ahead of time. So we let Gecko pass this data into
ScaledFonts which can then transmit the knowledge of whether the font has
color glyphs to the WR Mac font backend, which will then take appropriate
action.
Differential Revision: https://phabricator.services.mozilla.com/D130819
If GL is threadsafe, we can run on the compositor thread. This appears
to have performance benefits, possibly because the renderer thread is
too busy. If GL is not threadsafe, we must run the WebGL OOP instances
on the renderer thread.
At the time of writing, only the nouveau drivers on Linux are considered
to be not threadsafe, so most users will see WebGL running on the
compositor thread. This patch also adds prefers to override the
blocklist to either assume GL is threadsafe
(webgl.threadsafe-gl.force-enabled) and not threadsafe
(webgl.threadsafe-gl.force-disabled).
Differential Revision: https://phabricator.services.mozilla.com/D130634
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
Now that most calls to `profiler_thread_is_being_profiled` have been updated, the `ThreadProfilingFeatures` can be made compulsory, to force callers to think about what they really want to know about the current profiling state.
Differential Revision: https://phabricator.services.mozilla.com/D130010
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
We represent rects in WR with the Box2D format which uses a (p0, p1) representation.
When evaluating the size of these, the subtraction p1-p0 can potentially overflow the
i32 range, so we need to guard against this. Bug 1730695 consequently allows SWGL
to see much larger transforms than previously, which makes this a possibility.
Differential Revision: https://phabricator.services.mozilla.com/D130562
While working on this screenshot marker, I noticed that the lambda initialization could directly copy or move its needed captures, instead of going through separate copies on the stack, which was probably done before C++14 lambda were available to us.
Differential Revision: https://phabricator.services.mozilla.com/D130436
There were two structs claiming to be "CompositorScreenshot", which is not allowed. It was working because the JSON output was compatible, and handled in a special way in the front-end.
But it's better to combine the two structs into one, for consistency with other markers, and lower maintainability risks.
Differential Revision: https://phabricator.services.mozilla.com/D130435
Now that most calls to `profiler_thread_is_being_profiled` have been updated, the `ThreadProfilingFeatures` can be made compulsory, to force callers to think about what they really want to know about the current profiling state.
Differential Revision: https://phabricator.services.mozilla.com/D130010
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
