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
We create a clip region with the text length to make the decoration line
would be only drawn in the area. This allows the decoration line would
not be drawn multiple times when the text is being selected.
MozReview-Commit-ID: 4gjawk71eSu
--HG--
extra : rebase_source : 627fa77a2b6e17441d134255017762ebda92eaf6
The HasAuthorSpecifiedRules check was from the initial implementation
of text-shadow support on ::-moz-selection in bug721750. There doesn't
seem to be anything mentioning why this check is necessary.
Also given text-shadow is inherited by default, it doesn't seems this
change would lead to any difference.
MozReview-Commit-ID: 6Qbotdxykwi
--HG--
extra : rebase_source : 8c9894f297e4013d42bd0d535bcc7a1310c6bccc
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Also cleans up a bunch of TextDrawTarget code as fallout.
This is a significant perf win for textFrames.
MozReview-Commit-ID: J1BDkXZdvnc
--HG--
extra : rebase_source : 5a0769a53cadb55a074cfe5d718e259401fa7028
No rush merging this one around. Feel free to back this out if the crashes come back.
--HG--
extra : rebase_source : 5d850c0b739e8a47830a65da939241e495a1f7bf
This ensures the mutations TextOverflow does have already occured when we compute contents.
This also reverts my previous folded opacity patch, as this also handles that case.
MozReview-Commit-ID: 6A4F98GGHyL
--HG--
extra : rebase_source : 73c67ccf20f44ea808345a1146307fe9b9d9c3b1
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
Mostly just threading the TextDrawTarget deeper into the code to use a boolean.
A lot of places are trying to optimize away invisible text!
MozReview-Commit-ID: 89sDAwUv0HA
--HG--
extra : rebase_source : 8d800702232aec6626a33f2d6be893708d0bbfee
Selections in gecko are used to hack in style changes to subsets of text frames.
Mostly this works fine because decorations don't care where they are, and
textRunFragments already exist to do style changes midFrame. However we mishandled
shadows because we were assuming they applied to the entire run, which isn't
the case when shadows are involved.
Applying shadows to everything was desirable because the way nsTextFrame is written,
it's difficult for us to associate the glyphs and decorations with a "range".
However the selections iterator provides a natural grouping, so we use that.
The result is that TextDrawTarget effectively becomes an array of what TextDrawTarget
used to be (now called SelectedTextRunFragment). Everything else is just fallout
of this change.
MozReview-Commit-ID: 5GWPruo6daW
--HG--
extra : rebase_source : 8e1c1d61e43151ee6651f8c6cfbcb0912262df56
Multi-color shadow is not allowed in spec. We could use the same color
of the text as the color of the decoration line when we paint the
shadow.
MozReview-Commit-ID: AK9NoseSE0h
--HG--
extra : rebase_source : 48a84e73a7ee76b615c255a440cbe119fa8f56f0
Multi-color shadow is not allowed in spec. We could use the same color
of the text as the color of the decoration line when we paint the
shadow.
MozReview-Commit-ID: AK9NoseSE0h
--HG--
extra : rebase_source : 12b0aa45f5dbb938a35271dcadaa664ae4a82c1e