We can have markers with empty cause stacks, if we keep the timer running
without calling EnsureTimerStarted() again.
Differential Revision: https://phabricator.services.mozilla.com/D85457
FlipScreenPixels was heap-allocating and leaking a ScopedMap object, which kept
the surface alive.
Instead, we want to keep the surface alive just long enough to copy its data
into a Java Bitmap object. This copy needs to be done on the C++ side so that
we're sure that it happens while the surface data exists. After that, the Java
code can hold on to the resulting Bitmap object as long as it wants, since the
Bitmap then owns its own data.
The ScreenshotBuilder GeckoView API allows users to specify the bitmap object
that will be used. So rather than creating a new Bitmap object in the C++ code,
we pass the target bitmap into the C++ code that performs the copy.
As a drive-by fix, this patch eliminates another copy at the start of
FlipScreenPixels by replacing a call to `gfx::CreateDataSourceSurfaceFromData`
(which copies) with a call to `gfx::Factory::CreateWrappingDataSourceSurface`
(which doesn't copy).
It would be nice if we could eliminate another copy here, by performing the flip
during the copy into the Bitmap object. But I don't think there's a way to do
that. Also, for optimal performance, we probably want to get an AHardwareBuffer
object from the compositor and wrap that into a Bitmap.
Furthermore, the patch adds a check that makes sure the draw target was created
successfully before accessing it (throwing an exception if not).
Differential Revision: https://phabricator.services.mozilla.com/D85490
With fission enabled, walking the docshell tree to find unloaded
parents would stop at the first OOP parent. Instead we now walk
the `BrowsingContext`/`WindowContext` tree. To still check parents
which are OOP, we take advantage of the fact that a parent
`WindowContext` will no longer be the current `WindowContext` if
the parent was unloaded. For in process docshell's we additionally
check the docshell directly.
Differential Revision: https://phabricator.services.mozilla.com/D85328
FlipScreenPixels was heap-allocating and leaking a ScopedMap object, which kept
the surface alive.
Instead, we want to keep the surface alive just long enough to copy its data
into a Java Bitmap object. This copy needs to be done on the C++ side so that
we're sure that it happens while the surface data exists. After that, the Java
code can hold on to the resulting Bitmap object as long as it wants, since the
Bitmap then owns its own data.
The ScreenshotBuilder GeckoView API allows users to specify the bitmap object
that will be used. So rather than creating a new Bitmap object in the C++ code,
we pass the target bitmap into the C++ code that performs the copy.
As a drive-by fix, this patch eliminates another copy at the start of
FlipScreenPixels by replacing a call to `gfx::CreateDataSourceSurfaceFromData`
(which copies) with a call to `gfx::Factory::CreateWrappingDataSourceSurface`
(which doesn't copy).
It would be nice if we could eliminate another copy here, by performing the flip
during the copy into the Bitmap object. But I don't think there's a way to do
that. Also, for optimal performance, we probably want to get an AHardwareBuffer
object from the compositor and wrap that into a Bitmap.
Furthermore, the patch adds a check that makes sure the draw target was created
successfully before accessing it (throwing an exception if not).
Differential Revision: https://phabricator.services.mozilla.com/D85490
It was disabled on nightly in bug 1636998. It does nothing anymore.
There's no regression known and I'm hoping we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D85208
Ensure all listeners that are added are cleaned up correctly.
Add an option to remove the overlay when closed and add a promise for when
the dialog is set up.
Differential Revision: https://phabricator.services.mozilla.com/D85307
Change the GamepadEventChannel so it is fully-initialized by the IPC
constuctor and needs no separate "init" message, and so its completely
destroyed by the ActorDestroy() message so it needs no "cleanup" message.
This simplifies the object lifetime, as well as unifies the IPC error vs
clean shutdown paths.
Differential Revision: https://phabricator.services.mozilla.com/D85481
Instead of setting the mTargetConfirmed flag to false in APZCTreeManager when
potentially starting a drag block, let the input block creation do it a little
bit later. This change ensures that the InputQueue ReciveInputEvent methods
have access to the mHitScrollthumb flag, and so can make better decisions.
Differential Revision: https://phabricator.services.mozilla.com/D85452
Currently on Android when CompositorVsyncScheduler detects that we requested a
composite more than 2 vsync intervals ago it forces an immediate composite. This
is a relic from times when vsync observation occured on the main thread, and
Fennec was single-process. (The logic being that if the main thread was busy and
it would be better to composite immediately rather than wait for the vsync
notification.)
Neither of these conditions are true nowadays, and geckoview should be no worse
than desktop platforms in this regard, so let's remove this code.
Depends on D85611
Differential Revision: https://phabricator.services.mozilla.com/D85612
When a CompositorBridgeParent is initialized it reads the vsync duration from
the AndroidVsyncSource::Display instance. The vsync duration is currently
initialized in AndroidVsyncSource::EnableVsync(). Since bug 1617750 landed,
which makes the hidden window lazily loaded, the first tab's
CompositorBridgeParent is being initialized before vsync is enabled, meaning it
reads a value of zero.
Instead, initialize mVsyncDuration in the AndroidVsyncSource::Display
constructor.
Differential Revision: https://phabricator.services.mozilla.com/D85611
This patch is borrowing a change that's coming with D85239 to fix the issue that the Changes panel shows as empty when it should show changes tracked in the background (before the Changes panel is opened).
The reason, as identified in D85239, is that the Changes panel reacts to `DOCUMENT_EVENT` resources which are cached in the resource watcher. The Changes panel thinks that the document is reloading so it clears all the changes that were collected. The result in an empty Changes panel.
The screenshot below shows the resource types and the order in which they arrive:
{F2382929}
Differential Revision: https://phabricator.services.mozilla.com/D85603
Callers to `GetBuiltinPrototype()` rely on inlining the function itself plus
optimising the object access, so that the property value is directly seen as a
constant in the compiler. By changing `GetBuiltinPrototype()` and
`GetBuiltinConstructor()` to be directly translated into a JSOp, we can avoid
heavily relying on the compiler to optimise these two functions.
The new opcode replaces the existing JSOp::FunctionProto opcode. It doesn't
use JSProtoKey directly in order to help jsparagus (bug 1622530), but instead
uses its own set of mapping from enum values to built-in prototypes and
constructors.
This change also resolves bug 1377264.
Differential Revision: https://phabricator.services.mozilla.com/D84991
Jeremy Ir
Mats Palmgren
Botond Ballo
Dan Mosedale
Markus Stange
Chris Liu
Jeff Gilbert
Andreea Pavel
Butkovits Atila
Steven MacLeod
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Mark Banner
Mark Striemer
Jan-Ivar Bruaroey
Joel Maher
Geoff Brown
Chris Martin
Kartikaya Gupta
Jim Blandy
Jamie Nicol
sachin
Bob Clary
Razvan Caliman
André Bargull