Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
To allow MatrixDouble to be a drop-in replacement for gfxMatrix, it
needs to accept the "double" versions of Point, Rect, and Size. This
patch does that by adding some extra typedefs inside BaseMatrix to
abstract over that.
It also moves some function implementations into the .h file as they
don't need specialization. I left some function implementations in
the Matrix.cpp file:
- Rotation, because it is specialized for Float and Double, since it uses
sinf/cosf vs sin/cos in the two implementations.
- The Matrix4x4 multiplication operator overload, because if I put it
inside the BaseMatrix class declaration Matrix4x4 isn't defined yet
and the compiler doesn't like it.
MozReview-Commit-ID: K56dZjJhXWS
--HG--
extra : rebase_source : d009151942811a725ee6bf854238073e59665d5c
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
For RTL scrollframes the scrollable rect can extend into the negative-x coordinate
space as the user can scroll leftwards from the "zero" position. The code was
assuming a zero minimum scroll position in a couple of places which broke down
on RTL scrollframes.
MozReview-Commit-ID: 5FxELpafWSD
--HG--
extra : rebase_source : a3c7614528cf59a5c60f350fca84161c8586509f
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
These functions need to survive the gfxRect purge as they are used in a
few places.
MozReview-Commit-ID: 1jGNlmAvV49
--HG--
extra : rebase_source : 0becc3b969063b5797502a3414dfd6573e82eee0
Layers are retained between transaction and we store some data in the layers.
Thus, if we no longer use layers, we need find another storage to place
those data. I use frame's property to retain WebRenderUserData between
transaction.
MozReview-Commit-ID: Ku5VGBXa3w6
--HG--
extra : rebase_source : 636653f78d1d6c310726a1a2c944141dc691decc
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09