Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
As the data in the bug shows, the current default of opt-level=2 is
several minutes slower at compiling than opt-level=1. This slows down
builds significantly and the added benefits of running opt-level=2
for local development can't be justified for the common/default case.
This commit changes the default for local builds from opt-level=2 to
opt-level=1.
--enable-release (what we use for builds shipped to users) will imply
opt-level=2. --enable-optimize (the default) will use opt-level=1,
and --disable-optimize will use opt-level=0.
The RUSTC_OPT_LEVEL environment variable in mozconfigs can be used
to set an explicit opt-level level, regardless of what other
configure options are set. This includes the other potential values,
"s" and "z."
A side-effect of this change is that -Copt-level is now *always*
specified by the build system. Before, it was only specified if
the value was adjusted to 0 for --disable-optimize builds.
MozReview-Commit-ID: 67KX5qScnFc
--HG--
extra : rebase_source : dac0134e952151992eee23e017e9a29f84b05172
extra : intermediate-source : c3a7cc11a987aedb81332f1a03cd082ab0ab0cb8
extra : source : 360827b8a5956d58f7f0200431d3a44c57ce8dc4
Before this commit, RUSTFLAGS was derived in rules.mk by consulting
various variables set by configure. It isn't clear to me why things
are implemented this way. We don't appear to have moz.build level
overrides for Rust compiler flags. So there doesn't appear to be a
compelling reason why we can't derive these values in configure.
So, this commit ports the code for deriving default RUSTFLAGS from
rules.mk to toolchain.configure.
The port is pretty straightforward as far as the logic goes.
MozReview-Commit-ID: JhAE9Qlo8SK
--HG--
extra : rebase_source : 6186cb81cd37c516b3d645419b9461bf501d6ba2
The Rust optimization logic is tied to --enable-optimize/MOZ_OPTIMIZE
and --enable-debug/MOZ_DEBUG. In order to more easily implement more
customization, let's move --enable-optimize/MOZ_OPTIMIZE to
moz.configure so its value can be consulted there.
The logic here is a bit wonky. The option behaves like a boolean
or a string. If a string, MOZ_OPTIMIZE is set to 2. Otherwise it
is 1 or unset depending on the boolean value.
The custom compiler flags string is passed to old-configure, where it
overwrites whatever old-configure derived as the default value.
We stop short of moving all references to MOZ_OPTIMIZE_FLAGS to
moz.configure because there are a handful of them and I don't want
to scope bloat.
MozReview-Commit-ID: 6iNDu2HwLGr
--HG--
extra : rebase_source : a64f1236012d13913f21253df1b9b5ff0ae8ea6e
It is now closer in the file to where other default values are computed.
MozReview-Commit-ID: BffCEb6FAUP
--HG--
extra : rebase_source : 81b17131f9330d89818a36ffff625b672c19c01e
We mix the added and modified variables from mozconfig and sort them.
We also print comments indicating where values come from.
MozReview-Commit-ID: 97x9iHxZe3m
--HG--
extra : rebase_source : 367bc410bc06532a91b488039e3cb0ec65850c09
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
MozReview-Commit-ID: DpAhmLH3uJ2
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
Bug: 1406750
Reviewed-by: hiro
MozReview-Commit-ID: DpAhmLH3uJ2
Source-Repo: https://github.com/servo/servo
Source-Revision: 6035b75d399fbc9a8037743bb5199f3e1475333a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 27a734decabf029a00a5e735e477f3e7b9c5e46d
Currently pprint only checks for 'id' and 'class', and adds
those to the output. Given that lots of elements might not
have those attributes a couple more should be added, which
can help to uniquly identify those.
MozReview-Commit-ID: 3thefe4oLN3
--HG--
extra : rebase_source : e9d276229a39ce5169a333ecb5b1fcc10e935d2a
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
When setting up waiting for the browser after a wpt test with
--pause-after-test, we try to communicate with a possibly-defunct
browser instance. In this case we should instead just retun since
waiting doesn't make sense.
MozReview-Commit-ID: ILrXOOIagK1
--HG--
extra : rebase_source : 49106c9ff86dcfc17d38e249c8db232b8ca31d61
This is pretty much a straight-forward change except for a single thing, the
UpdateInsertionParent calls.
However, I cannot make any sense of them. They go through the inserted children
setting the insertion point, but then ClearInsertionPoints() is called.
ClearInsertionPoints calls XBLChildrenElement::ClearInsertedChildren, which sets
all the insertion points to null anyway.
Thus, I've removed that function completely.
MozReview-Commit-ID: 80daGQfLZrV
--HG--
extra : rebase_source : d52a37a60147ac11794c3cfe1aad5d202e9d2d9f
We could also check whether it is a subdocument frame or what not (not that
we're going to render anything down there). But at that point the value of
avoiding the FFI call starts diluting.
MozReview-Commit-ID: BBIv0O3fFuk
--HG--
extra : rebase_source : 663ead4fe3df83ea1d929b8726c8c1ab8b05c06a
Always set aNoReferrer = true in openLinkIn when where == 'window' and aIsPrivate
MozReview-Commit-ID: 7szUyO6w6d4
--HG--
extra : rebase_source : 25f00b0967bc7ed1e755227c6d16224b411d5e38
Once we add fallback chain to GetRequestedLocales we can slightly improve the
locale negotiation for extensions. I made it tighter against just `en-US` because
in the future it is possible that RequestedLocales fallback chain will not contain
en-US in some scenarios, and it seems that for WebExtensions en-US should be the
last resort no matter what.
The other change is a fix to a regression I introduced when switching to LocaleService,
that somehow noone noticed.
MozReview-Commit-ID: FH6cePcoi0R
--HG--
extra : rebase_source : 7e253fb940c153c3522a6aa41139fbf703c7266b
