I don't have a strong preference about blending with white vs. just doing alpha
0.5, so I kept doing what we were doing, since Blink and WebKit also apply the
blending to the text background, and I'm not sure that's particularly desirable.
MozReview-Commit-ID: AwYtAgdlcxj
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
--HG--
extra : rebase_source : 81e62163bf41a5d5dd87abf5397e6e8c62ed4096
extra : source : 653a9fc279e2f6a6d066474a94a70d65ac703d6b
The textBreakPoints variable and its related logic are copied from
BuildTextRunForFrames, however, they are not used in
SetupLineBreakerContext at all. Remove the variable allocation and the
unnecessary while loop.
MozReview-Commit-ID: 1AsA6V7aGMh
--HG--
extra : rebase_source : 408b1e4a44e7a7f41be9cafdb72392ed5f518f37
It's good to save some copy constructor calls.
MozReview-Commit-ID: 6TveqwkOvc0
--HG--
extra : rebase_source : 02e678f985c074f6c972cf8478e233aa5e4607db
In the current implementation, when hyphens property is set to auto, we do some
math to determine the index of text fragment, so we can check whether a character
is an explicit hyphen. However, the math calculation is not reliable, and it is
not easy to calculate the fragment index when there are more than one fragments
in a gfxTextRun, e.g., a paragraph which consists multiple inline elements.
In this patch, we simply use GetOriginalOffset() to get the position relative
to the current text fragment, and scan/detect explicit hyphens correctly.
MozReview-Commit-ID: JIg3tdpViRH
--HG--
extra : rebase_source : a6ac03914badd2f2dcd238186a6653e8660bc116
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U