This is accomplished via prefs rather than using a reftest attribute because
it's easier to get the right persistence (that is, how long the fixed margins
stick around) this way. The downside is that someone reading the reftest page
needs to look at the test- or ref-specific prefs in reftest.list to get a full
picture of what the test is doing.
Differential Revision: https://phabricator.services.mozilla.com/D28728
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
When GPU process does not exist, Render thread is created by gfxPlatform::InitLayersIPC(). Then gfxVars::SetProfDirectory() is called after RenderThread::InitDeviceTask(). Then WebRenderProgramCache could not get correct gfxVars::ProfDirectory() value. It affects to webrender shader disk cache.
Differential Revision: https://phabricator.services.mozilla.com/D28793
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsDocumentViewer` which is the only
implementation of `nsIContentViewer` use `mozilla::PresShell` directly
rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D27470
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
ImageEncoder::ExtractDataInternal takes a `const nsAString&` for its
options, but flattens it into a null-terminated `nsString` so callees
can take a `char16_t*`. But nearly all of those callees eventually wind
up calling ImageEncoder::GetInputStream, which just constructs an
`nsDependentString` from the passed character pointer.
There's no reason to do all this extra work. We can just pass the
original options reference all the way through the stack and avoid
needless conversions.
Differential Revision: https://phabricator.services.mozilla.com/D26353
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
As discussed on IRC, fixed is only used for prefs right now, and:
* We already copy the fixed size to the monospace font.
* We already serialize the fixed family as "monospace" in the style system.
So it already works somewhat inconsistently. Making it an alias makes it
work consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24288
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
As discussed on IRC, fixed is only used for prefs right now, and:
* We already copy the fixed size to the monospace font.
* We already serialize the fixed family as "monospace" in the style system.
So it already works somewhat inconsistently. Making it an alias makes it
work consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24288
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
This will allow upcoming shared font-list to use the same helpers as the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D22926
--HG--
extra : moz-landing-system : lando
This allows us to reduce #include usage of the massive gfxFont.h header,
and keeps this specialized kind of TextRange struct local to where it's used.
Differential Revision: https://phabricator.services.mozilla.com/D22904
--HG--
extra : moz-landing-system : lando
UA style sheets only ever specify a single generic font family in font-family
properties, so we pre-create a unique, static SharedFontList for each generic
and change the representation of FontFamilyList to be able to refer to them
by their generic ID. This avoids having to share refcounted SharedFontList
objects across processes.
Depends on D17182
Differential Revision: https://phabricator.services.mozilla.com/D17183
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
While we're here, fix the measurement of ' ' and 'x' so that we don't
measure the .notdef glyph if those glyphs aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D23423
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
Chrome has had it enabled for years, we had disabled it originally due to crashes seen on Windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D23656
--HG--
extra : moz-landing-system : lando
Adds early exit if not originating in the parent process when recording
display HDR capability. This helps to remove more win32k usage from
content processes.
Differential Revision: https://phabricator.services.mozilla.com/D23051
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
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).
In this case, moving ShutdownTileCache()'s function declaration to the header file TiledContentClient.h means the same declaration will be seen by the TiledContentClient.cpp file defining the function and the gfxPlatform.cpp calling the function.
gfx/layers/client/TiledContentClient.cpp:337:6 [-Wmissing-prototypes] no previous prototype for function 'ShutdownTileCache'
Differential Revision: https://phabricator.services.mozilla.com/D20267
--HG--
extra : source : 495273cd3fdc65f353d5562573503fc897760603
extra : histedit_source : fab19badff1cadd66212cf182978217b398c0fe6
Preferrably CreateOffscreenContentDrawTarget would create Capture DrawTargets when we intend to use OMTP. This is not the case at the moment though and changing this would likely introduce more unforseen issues. For now all of these calls basically mean a DrawTarget will be used on the main thread and we should use a no-op ClearRect to ensure that the DrawTarget is actually initialized. Since IsValid for the moment won't do this for DrawTargetD2D. (See bug 1521368)
--HG--
extra : rebase_source : 6a5c1732d3908be748ea4d05668f4a7562828f6a
Preferrably CreateOffscreenContentDrawTarget would create Capture DrawTargets when we intend to use OMTP. This is not the case at the moment though and changing this would likely introduce more unforseen issues. For now all of these calls basically mean a DrawTarget will be used on the main thread and we should use a no-op ClearRect to ensure that the DrawTarget is actually initialized. Since IsValid for the moment won't do this for DrawTargetD2D. (See bug 1521368)
Differential Revision: https://phabricator.services.mozilla.com/D21037
--HG--
extra : rebase_source : 7b9f4c5ed66d5ecaf613634c660f085de3584fd3
Implements a 50ms buffer of scale events in APZC, so pinch locking code can
consider gesture movement over a fixed length of time. Previously, pinch
locking was sensitive to event frequency (which is determined by the
sensitivity of the input device).
* New class InputBuffer wraps std::deque
* New field APZC::mPinchEventBuffer
* New gfxPref APZPinchLockBufferMaxAge
--HG--
extra : rebase_source : a44da4c3ce971fee1b0f401357f47f994a9145df
This patch is changing a way to get ClearType paramters because registry key
may not be present. CreateMonitorRenderingParams() will return default values
if the corresponding registry key is not present.
--HG--
extra : source : 765a6f1fa3e7cbda3d841661fa3b4f71ad1b5ed1
Looks like this is not needed anymore and we can just use SurfaceTexture
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D20527
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
This should help increase our WebRender usage so we're more likely to learn
about problems with minimal additional risk.
Differential Revision: https://phabricator.services.mozilla.com/D18020
--HG--
extra : moz-landing-system : lando
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