I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : ca7a35bb9f5e27880d5dc62e03feb91b6ac3435d
ScreenHelperGTK is the platform dependent part of the original
nsScreenManagerGtk and nsScreenGtk. It registers monitors-changed
event listener from gtk and pushes updates to ScreenManager. See patch
part 4. for how ScreenManager works.
MozReview-Commit-ID: KBo7ZLFTjM3
--HG--
rename : widget/gtk/nsScreenManagerGtk.cpp => widget/gtk/ScreenHelperGTK.cpp
rename : widget/gtk/nsScreenManagerGtk.h => widget/gtk/ScreenHelperGTK.h
extra : rebase_source : 5607e31b62c928934cc45df7b2212428fbfd79c1
This will add "WR?" if the pref is not set to true, or "WR!" if the pref is set
to true (which indicates the user flipped it), followed by "WR+" or "WR-" which
indicates whether or not WebRender is enabled.
MozReview-Commit-ID: F3h5UowCxij
--HG--
extra : rebase_source : e809a9026c35d89c101e6cb72d09cd6136ed84c6
gfxWindowsPlatform overrides InitAcceleration, and the override calls
InitGPUProcessSupport, which may disable the GPU process. Therefore, in
order to capture this scenario, we need to initialize WebRender after
the subclass implementation has run, rather than at the end of the base
class implementation, which is before InitGPUProcessSupport has run.
The cleanup work includes:
part 1: make all methods 'const' for the abstract class of PropertyProvider.
part 2: make nsFontMetrics's StubPropertyProvider final.
part 3: make nsTextFrame's PropertyProvider final.
Make some methods 'const' and some variables 'mutable', so we could let all the
overridden methods stay const.
We also need to make the pass-in parameter of gfxFontGroup's GetHyphenWidth const.
Note that the comment of GetHyphenWidth seem outdated, so I fixed it as well.
part 4: make the member variables in nsTextFrame's PropertyProvider to be 'const'.
Make all the member variables 'const' except mStart, mLength,
mJustificationArrayStart, and mJustificationSpacings.
The static function AdvanceToNextTab is fixed since we only use 2 of the 4 parameters.
part 5: coding style fix for nsTextFrame's PropertyProvider.
MozReview-Commit-ID: 1kbWPwx27aQ
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : bc338b1a33f1dbf209706577b2455315dfb855e2
Now that we don't support XP it's reasonable for us to drop support for GDI
fonts and rely solely on DirectWrite. We should start this process by removing
support for building without DirectWrite.
This adds back a MOZ_ENABLE_WEBRENDER define, which only controls whether or
not WebRender is enabled at runtime. The default behaviour is changed so that:
- if the user specifies --disable-webrender in the mozconfig, WebRender is
neither built nor enabled
- if the user specifies --enable-webrender in the mozconfig, WebRender is
built and enabled
- if the user specifies --enable-webrender=build in the mozconfig, WebRender is
built but not enabled, except on Android where it is neither built nor enabled
- if the user doesn't specify any of the above, the default behaviour is:
- on nightly/local builds, the same as --enable-webrender=build
- on other channels (e.g. aurora), the same as --disable-webrender
The net effect is that local/Nightly-automation builds will have WebRender
built-in but not enabled where possible (i.e. not Android). However the user
can override this behaviour via mozconfig options to either not build WebRender
at all, or to enable it in addition to building it.
MozReview-Commit-ID: IM7DdSHkIB
This function is not a virtual function and always returns CAIRO_STATUS_SUCCESS
after the patch in bug 1054838 landed. There is no reason to keep it anymore.
MozReview-Commit-ID: EadrrFQyjfY
--HG--
extra : rebase_source : 3f6a284dc9fa396d5cfd3f64190562373801a0a2
Currently the profiler mostly uses an array of strings to represent which
features are available and in use. This patch changes the profiler core to use
a uint32_t bitfield, which is a much simpler and faster representation.
(nsProfiler and the profiler add-on still use the array of strings, alas.) The
new ProfilerFeature type defines the values in the bitfield.
One side-effect of this change is that profiler_feature_active() now can be
used to query all features. Previously it was just a subset.
Another side-effect is that profiler_get_available_features() no longer incorrectly
indicates support for Java and stack-walking when they aren't supported. (The
handling of task tracer support is unchanged, because the old code handled it
correctly.)
Here we add a new UserFontLoadState value, STATUS_LOAD_PENDING, which
represents the state just after a gfxUserFontEntry's url()-valued source
would being loading, except that we can't start the load due to being
on a Servo style worker thread. In that case, we defer the work of
initiating the load until just after the Servo traversal is finished.
URLs that can normally be loaded synchronously, such as data: URLs
and script-implemented protocols marked as synchronous, must be
handled asynchronously when encountered during Servo traversal, since
various main-thread only work (in FontFaceSet::SyncLoadFontData) must
happen. This is a user visible change from stock Gecko, but should
only happen when font metrics for a data: URL font are requested
due to ch/ex unit resolution when layout hasn't previously requested
the font load. Hopefully nobody relies on synchronous resolution of
ch/ex units with data: URLs.
We unfortunately also can't pick gfxUserFontEntry objects out of the
UserFontCache during Servo traversal, since validating the cache
entry involves doing content policy checking, which is not thread-safe
(due in part to taking strong references to nsIPrincipals).
Platform fonts and ArrayBuffer-backed DOM FontFace objects continue
to be handled synchronously.
The PostTraversalTask does not take a strong reference to the
gfxUserFontEntry object, since it is held on to by the DOM FontFace
object, which itself won't go away before the PostTraversalTask
is run.
MozReview-Commit-ID: J9ODLsusrNV
--HG--
extra : rebase_source : d3e3d1dc187cb252750b57bcecd0b1ed77a15a7c
As with a few other gfx* font-related classes, during font metrics
calculations we end up taking strong references to gfxUserFontSet,
and it would be difficult to restructure the code to not do this.
MozReview-Commit-ID: L1GbZnf4825
--HG--
extra : rebase_source : 3bc2deb24e282f4a76f0a270d28771016052f9ec
Here we add a new UserFontLoadState value, STATUS_LOAD_PENDING, which
represents the state just after a gfxUserFontEntry's url()-valued source
would being loading, except that we can't start the load due to being
on a Servo style worker thread. In that case, we defer the work of
initiating the load until just after the Servo traversal is finished.
URLs that can normally be loaded synchronously, such as data: URLs
and script-implemented protocols marked as synchronous, must be
handled asynchronously when encountered during Servo traversal, since
various main-thread only work (in FontFaceSet::SyncLoadFontData) must
happen. This is a user visible change from stock Gecko, but should
only happen when font metrics for a data: URL font are requested
due to ch/ex unit resolution when layout hasn't previously requested
the font load. Hopefully nobody relies on synchronous resolution of
ch/ex units with data: URLs.
We unfortunately also can't pick gfxUserFontEntry objects out of the
UserFontCache during Servo traversal, since validating the cache
entry involves doing content policy checking, which is not thread-safe
(due in part to taking strong references to nsIPrincipals).
Platform fonts and ArrayBuffer-backed DOM FontFace objects continue
to be handled synchronously.
The PostTraversalTask does not take a strong reference to the
gfxUserFontEntry object, since it is held on to by the DOM FontFace
object, which itself won't go away before the PostTraversalTask
is run.
MozReview-Commit-ID: J9ODLsusrNV
--HG--
extra : rebase_source : 1651e2917bd31b87fc1c1be94b0eced1273df86a
As with a few other gfx* font-related classes, during font metrics
calculations we end up taking strong references to gfxUserFontSet,
and it would be difficult to restructure the code to not do this.
MozReview-Commit-ID: L1GbZnf4825
--HG--
extra : rebase_source : bfd83b02cceec747dc4f4f021eff205e7aaa2b69
Since font-language-override can only have a single three-letter tag, and it is
eventually converted to uint32_t while creating gfxFontStyle, we should be able
to move the conversion ahead, to an earlier stage.
In this patch, we move the ParseFontLanguageOverride to nsRuleNode, so we could
do the nsString-to-uint32_t conversion during computing time.
MozReview-Commit-ID: LA4Bv3wV7K
--HG--
extra : rebase_source : 48059a9913d58363f78dea59b1b7811d9f038352
This is a largely uninteresting patch that just uses the DisplayListBuilder
directly. A wonderful cleanup patch will come after this. One of the more
interesting pieces is the use of PushBuiltDisplayList. This is needed for
handling empty transactions. See https://github.com/servo/webrender/pull/934
for more info.
This member-var has type 'UniquePtr', but (up until this patch) its value
is set up using "new" and raw pointers. This patch improves that codepath by
using UniquePtr & MakeUnique, for stronger ownership guarantees.
MozReview-Commit-ID: KWZVpvr9bYj
--HG--
extra : rebase_source : 4e46d355078c7da6ae750f3ca06586dc8703e8a7
Also making SetupClearTypeParams more robust:
* Using W functions instead of A functions.
* Checking the value range again after taking the enhancedContrast value from the registry.
* Adding error checks after CreateCustomRenderingParams calls.
MozReview-Commit-ID: I7Lr6SCqiRz
--HG--
extra : rebase_source : 50dfe6b233bb09b49057e96f8df558eea4554ec8
This member-var has type 'UniquePtr', but (up until this patch) its value
is set up using "new" and raw pointers. This patch improves that codepath by
using UniquePtr & MakeUnique, for stronger ownership guarantees.
MozReview-Commit-ID: KWZVpvr9bYj
--HG--
extra : rebase_source : 4e46d355078c7da6ae750f3ca06586dc8703e8a7
Instead of just reporting the value of the pref, also make sure that about:support
incorporates the runtime check of whether or not a touch device was discovered
in the widget code. The code to do this already exists in TouchEvent::PrefEnabled,
so we can just reuse that.
MozReview-Commit-ID: DN7FSlsDwD1
--HG--
extra : rebase_source : efb3d66e1669f8f2b038888ef2b1c8bb83f1c710
This option turns on a frame counter that is shown in the top left corner via a
QR code. It was designed to be used in video recordings of B2G phones.
It no longer seems useful, so this patch removes it.
* * *
Bug 1357298 - Remove all traces of frame numbers and power from the profiler output. r=mstange.
--HG--
extra : rebase_source : 0ce87963ce375df64bb8d80ef2b5d40ea507bc7c
Even for very small layers we want to avoid doing work on the main
thread.
At the same time, however, increase the minimum active layer size for
animations which come from restyles. These involve the main thread
anyway, so there is less to be gained from using an active
layer. Since switching items between active and inactive can have
large knock-on effects, we want to make sure it really is worth making
the layer active.
MozReview-Commit-ID: 8N6xlVW4Dp3
--HG--
extra : rebase_source : bd9a97899faaf187e5e148126711bb0ff5a29ee6
The issue is that with Osaka becoming a downloadable asset rather than a
universally pre-installed font, it's possible for a user's system to be in
a state where the Osaka-Regular face is present (and therefore the Osaka
family shows up in the main font family list), but Osaka-Mono has still not
been downloaded. Until recently, I wasn't aware that the family could be in
that partially-installed state, but apparently it does happen (perhaps
depending on how the download was originally triggered).
The download prompt then occurs when we use LookupLocalFont() to find the
Osaka-Mono face, because that calls CGFontCreateWithFontName, which is
aware of the downloadable font assets; so when it is asked for Osaka-Mono,
and sees that it hasn't been downloaded, it offers to help out.
We tried to avoid this by checking for the presence of the Osaka family
before calling LookupLocalFont(), and that solved things for most users
(where the Osaka family was either fully installed or not installed at
all), but it fails in the case where the Regular face is present but Mono
isn't.
So this patch works around that by avoiding LookupLocalFont (and therefore
CGFontCreateWithFontName) altogether, and instead searching the faces
actually present in the main Osaka family. If Osaka-Mono is installed, it
will be found there and we can then duplicate its font entry and create the
separate Osaka-Mono family; and if not, we safely (and silently) ignore it.
cku
Wes Kocher
Lee Salzman
Nicolas Silva
Kan-Ru Chen
Kartikaya Gupta
Carsten "Tomcat" Book
sotaro
Jeff Muizelaar
Andrea Marchesini
Ethan Lin
Jeremy Chen
Daosheng Mu
Sebastian Hengst
Jeff Gilbert
Mason Chang
Boris Zbarsky
Zibi Braniecki
Kearwood Gilbert
Bas Schouten
Jonathan Kew
Nicholas Nethercote
David Anderson
Cameron McCormack
Iris Hsiao
Jeff Gilbert
Ryan Hunt
Daniel Holbert
Masatoshi Kimura
Milan Sreckovic
David Major
Timothy Nikkel
Ryan VanderMeulen
Benjamin Smedberg
Botond Ballo
Miko Mynttinen
Jamie Nicol
Morris Tseng
George Wright
Tom Tromey
Andrew Osmond
Sylvestre Ledru