To facilitate testing of document splitting before it is preffed on,
I'm adding a pref to disable clearing the texture cache, since this
will currently crash the browser with doc splitting on.
Depends on D13840
Differential Revision: https://phabricator.services.mozilla.com/D13841
--HG--
extra : moz-landing-system : lando
gfxUtils::EncodeSourceSurface no longer uses a stringly-typed API to create a
`imgIEncoder` for the relevant MIME type. Instead, we now use an enum class and
switch on it to create the encoder.
Depends on D14816
Differential Revision: https://phabricator.services.mozilla.com/D14817
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Also, if "Use hardware acceleration when available" is disabled, restrict webgl to the igpu.
Differential Revision: https://phabricator.services.mozilla.com/D19059
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
With bug 1509358 having landed we don't need a draw target in a bunch of
places. This removes it from those places.
Differential Revision: https://phabricator.services.mozilla.com/D15481
--HG--
extra : moz-landing-system : lando
Disable SkiaGL on WebRender, since there is a case that R8G8B8X8 is used, but WebRender does not support R8G8B8X8 yet. And SkiaGL is already disabled by Bug 1468801.
Differential Revision: https://phabricator.services.mozilla.com/D14366
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
The gfx pref machinery asserts when user-level values are set that
environment and runtime prefs have not been set. This effectively means
we need to make all user-level decisions before calls to ForceDisable(),
and the code in question here violates that contract.
This branch is not necessary for correctness, since the pref basically
means "enable WR on qualified hardware", and we can just ignore that
request if the hardware is not qualified. It does provide extra
about:support information, but we also get that information from the
recording in WebRenderHardwareQualificationStatus, which creates a
separate decision log for WEBRENDER_QUALIFIED. In this case, it will
report something like:
"WEBRENDER_QUALIFIED: blocked by env: No qualified hardware"
which should be enough here.
Differential Revision: https://phabricator.services.mozilla.com/D14082
The gfx pref machinery asserts when user-level values are set that
environment and runtime prefs have not been set. This effectively means
we need to make all user-level decisions before calls to ForceDisable(),
and the code in question here violates that contract.
This branch is not necessary for correctness, since the pref basically
means "enable WR on qualified hardware", and we can just ignore that
request if the hardware is not qualified. It does provide extra
about:support information, but we also get that information from the
recording in WebRenderHardwareQualificationStatus, which creates a
separate decision log for WEBRENDER_QUALIFIED. In this case, it will
report something like:
"WEBRENDER_QUALIFIED: blocked by env: No qualified hardware"
which should be enough here.
Differential Revision: https://phabricator.services.mozilla.com/D14082
--HG--
extra : moz-landing-system : lando
The latter causes confusion in the memory reports because it gets summed
up and thus effectively doubles the reported texture memory usage. I've
decided it's best to drop, and so might as well do that while we're
already messing around with the memory reports and the associated
boilerplate.
Depends on D13439
Differential Revision: https://phabricator.services.mozilla.com/D13440
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Simplify error handling in GLContext.
Modernize context loss handling in GLContext.
Remove various unused parts.
Fix WebGLContext's context loss/restoration.
MozReview-Commit-ID: Lu2hi5HnP8x
Differential Revision: https://phabricator.services.mozilla.com/D12496
--HG--
extra : moz-landing-system : lando
The GDI font code path is very rarely used, further when it used we
don't ever seem to get any DrawTarget that's not Skia and so never try
to pull the DC out of the DrawTarget anyways. I tested this by forcing
on GDI fonts, running the browser and printing, with and without e10s.
However, Jonathan Kew was able to trigger this path. I'm not sure why.
Making this change will let us rip out a bunch of code that threads the
DrawTarget through the text code.
Differential Revision: https://phabricator.services.mozilla.com/D12689
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/thebes/gfxBlur.cpp:444:6 [-Wmissing-prototypes] no previous prototype for function 'CacheBlur'
gfx/thebes/gfxPlatform.cpp:1087:6 [-Wmissing-prototypes] no previous prototype for function 'IsFeatureSupported'
gfx/thebes/gfxPlatform.cpp:1355:6 [-Wmissing-prototypes] no previous prototype for function 'SourceBufferDestroy'
gfx/thebes/gfxPlatform.cpp:1365:6 [-Wmissing-prototypes] no previous prototype for function 'SourceSurfaceDestroyed'
gfx/thebes/gfxPlatform.cpp:2422:6 [-Wmissing-prototypes] no previous prototype for function 'VideoDecodingFailedChangedCallback'
gfx/thebes/gfxPlatform.cpp:559:6 [-Wmissing-prototypes] no previous prototype for function 'WebRenderDebugPrefChangeCallback'
widget/GfxInfoBase.cpp:82:6 [-Wmissing-prototypes] no previous prototype for function 'InitGfxDriverInfoShutdownObserver'
Differential Revision: https://phabricator.services.mozilla.com/D20260
--HG--
extra : source : b8333099bca51db166839862e4a3918c5e8874f2
extra : intermediate-source : acb4bb2466df7fb22ca1a76e13c79186ea938bc1
extra : histedit_source : 16cf3a96596046e8111774a147b23ade0676c8e1
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
This is not really the best fix (a better one would be to ensure that the
displayport is set on the root element of the gfx sanity window), but should
do as a stopgap solution.
Differential Revision: https://phabricator.services.mozilla.com/D9667
--HG--
extra : moz-landing-system : lando
This is what we have been working towards in all of the previous parts
in the series. This subclasses AnimationFrameDiscardingQueue to save the
discarded frames for recycling by the decoder, if the frame is marked as
supporting recycling.
Differential Revision: https://phabricator.services.mozilla.com/D7516
Add a pref called gfx.font_ahem_antialias_none which disables
antialiasing for any font with the family name "Ahem". This is useful
for wpt reftests where antialaising of Ahem causes spurious failures.
Differential Revision: https://phabricator.services.mozilla.com/D7200
This was an experiment before we had e10s. It's no longer needed.
Depends on D7922
Differential Revision: https://phabricator.services.mozilla.com/D7924
--HG--
extra : moz-landing-system : lando
This changes the containerful scrolling pref to be an override pref
such that it is:
- always false on desktop (i.e. always use containerless there)
- always true in Fennec (i.e. never use containerless there)
- true in GeckoView if WebRender is disabled (i.e. only use
containerless with WebRender).
The first two cases are the same as before; the last case is new.
Because we don't create layers with WR, the containerless vs
containerful distinction doesn't make much sense there, and we need to
implement a bunch of zooming glue in either case. So it makes sense to
go with the "way of the future" and keep it containerless.
Differential Revision: https://phabricator.services.mozilla.com/D8733
--HG--
extra : moz-landing-system : lando
It just doesn't work.
We add the preference media.wmf.force.allow-p010-format to force enable it.
Depends on D8136
Differential Revision: https://phabricator.services.mozilla.com/D8310
--HG--
extra : moz-landing-system : lando
This allows to more easily construct it and add new values as needed.
The other bool members could be made to be part of the set, but this would require more significant code change.
Depends on D8082
Differential Revision: https://phabricator.services.mozilla.com/D8129
--HG--
extra : moz-landing-system : lando
All of its callers are in painting code, so changes will take effect on the
next paint, so there is no need for it to be a Once pref.
Making it Live allows us to selectively enable it in specific mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D7340
--HG--
extra : rebase_source : 772e3c49f5e945d37126979b1c1edab691788e63
extra : histedit_source : 34eccab0c8ab664f15787626bff72f261718ea9c
We are refactoring much of the code in gfx/vr, moving
most of the code that runs in the VRListenerThread into
it's own process. The remaining code will be non-blocking
once this refactoring is complete.
In order to resolve some shutdown crashes, it is simpler
to remove the VRListenerThread and the related code
starting and stopping this thread. If this is done
prior to completion of the refactoring for Bug 1473399
(Enable VRService thread by default), there would be a
regression in responsiveness during detection of VR
hardware due to blocking API calls moving off the thread.
Differential Revision: https://phabricator.services.mozilla.com/D7227
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
This patch enables the compositor process memory reporting for both the
dedicated GPU process case, and the integrated with the main process
case. This will simply cause us to list all of the entries in the shared
surfaces cache to show what is presently mapped in.
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
This patch enables the compositor process memory reporting for both the
dedicated GPU process case, and the integrated with the main process
case. This will simply cause us to list all of the entries in the shared
surfaces cache to show what is presently mapped in.
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
> dom/media/gmp/CDMStorageIdProvider.cpp(63,10): warning:
> local variable 'storageId' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClip.cpp(581,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClipChain.cpp(88,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/nsDisplayList.cpp(179,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> gfx/thebes/gfxWindowsPlatform.cpp(454,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Will remove std::move().
> gfx/thebes/gfxFontEntry.cpp(245,20): warning:
> local variable 'name' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> netwerk/cookie/nsCookieService.cpp(4460,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
GetPathFromURI() result is stored in an nsAutoCString, so it might as well return that type.
> toolkit/components/extensions/WebExtensionPolicy.cpp(462,12): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
> toolkit/components/extensions/WebExtensionPolicy.cpp(475,10): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
`result` may be empty or may be arbitrarily long, so I'll use nsCString inside the function.
> toolkit/xre/CmdLineAndEnvUtils.h(349,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Returning an UniquePtr, will remove std::move().
Also will `return s` instead of `return nullptr` when `(!s)`, to avoid extra construction which could also prevent elision (not entirely sure, but it's at least not worse!); and it's clearer that the two `return`s return the same already-constructed on-stack object.
> tools/profiler/core/shared-libraries-win32.cc(111,10): warning:
> local variable 'version' will be copied despite being returned by name [-Wreturn-std-move]
nsPrintfCString -> nsCString, will add std::move().
> xpcom/glue/FileUtils.cpp(179,10): warning:
> local variable 'fullName' will be copied despite being returned by name [-Wreturn-std-move]
> xpcom/glue/FileUtils.cpp(209,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
nsAuto{,C}String -> ns{,C}String, will add std::move().
This allowed removals of 'AllowCompilerWarnings' from layout/painting,
netwerk/cookie, and toolkit/components/extensions.
Differential Revision: https://phabricator.services.mozilla.com/D5425
--HG--
extra : moz-landing-system : lando
This function uses a nsAutoString internally, and its caller stores its
returned value in a nsAutoString. So it's silly for us to have it return a
different type (nsString). With this change, the compiler should be able to
perform return value optimization and avoid the need for any
copying/reallocation of this function's return value.
Differential Revision: https://phabricator.services.mozilla.com/D3926
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
This commit adds the ability to create a different kind of DrawTargetCapture which
has a limit on the size of which its CaptureCommandList can grow before it is
synchronously flushed to its destination DrawTarget.
Special care is taken to not do a sync flush until we would need to resize
the backing store of the CaptureCommandList. This allows us to not waste
memory we've already allocated.
The async painting content clients are updated to use it, and get a default
value from a new preference.
MozReview-Commit-ID: CJL7ffvaRzR
--HG--
extra : rebase_source : 546d9838808320c51d9ceef0ed0ffcbb88a16269
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This commit adds the ability to create a different kind of DrawTargetCapture which
has a limit on the size of which its CaptureCommandList can grow before it is
synchronously flushed to its destination DrawTarget.
Special care is taken to not do a sync flush until we would need to resize
the backing store of the CaptureCommandList. This allows us to not waste
memory we've already allocated.
The async painting content clients are updated to use it, and get a default
value from a new preference.
MozReview-Commit-ID: CJL7ffvaRzR
--HG--
extra : rebase_source : f646862dcef7a480b21dfb7ddb1fa165338ba506
extra : source : b865a866fe5a3257615cb54b7e5e790cc9331988
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
This adds a WEBRENDER_QUALIFIED feature that's set whenever the webrender could
be used on a machine regardless of whether it's actually being used.
MozReview-Commit-ID: Eke6PMKQOnx
--HG--
extra : rebase_source : 977d371c12c9e8ab3273d6e65655e0378c22c226
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
VSync on Wayland is a bit tricky as we can get only "last VSync" event signal with
CLOCK_MONOTONIC timestamp or none (if application is hidden/minimized).
That means we should draw a next frame at "last Vsync + frame delay" time and also
approximate next VSync event when we don't get any.
MozReview-Commit-ID: FI3Z4nkmDNK
--HG--
extra : rebase_source : 8a0f6148990cf4e7ad26ff287eadff87cb0215fc
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This pref can be used by users to force-disable WebRender. It is
recorded in the telemetry environment so we can get a sense of how many
people are setting this pref.
MozReview-Commit-ID: yZSN44NMvD
--HG--
extra : rebase_source : d355236773f63da0f6acb5341f4ae6a88cd0a488
This pref was used to enable the building of nsDisplayLayerEventRegions
items without APZ, so that we could test it in isolation. However, we no
longer need to do so, and these display items are going to be deleted
anyway, so we can remove this pref.
MozReview-Commit-ID: LJVcFafCKyS
--HG--
extra : rebase_source : 76d8eeca8dca4ea88b8226bbe6b829dbc40e03e4
This removes the gfx.webrender.hit-test pref, assumes a value of true
everywhere it is used, and deletes all the resulting dead code.
Some gtests were setting this pref to false, and they are now updated to
set gfxVars::UseWebRender to false instead, which has the desired effect
of using the non-WR hit-testing codepath in APZ. (The data needed for
this codepath is set up by the gtests themselves).
MozReview-Commit-ID: 9ljDr8eEnv1
--HG--
extra : rebase_source : fbc321861428e7bb0bf7ab811935b682785debdc
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
