If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
The code in ComputeSuitableScaleForAnimation feeds its double-based
computation results into GetSuitableScale, which takes and returns
floats. Also the double-based computation that it's doing involves
calling UpdateMinMaxScale a bunch which explicitly uses the float
variant of std::min and std::max. And all of this is used from
ChooseScaleAndSetTransform which does other things like call a
"RoundToFloatPrecision" function, and casts the final values to
floats before setting the layer's prescale. So let's just use
floats all the way through.
MozReview-Commit-ID: BE3WC5hv89d
--HG--
extra : rebase_source : 987d9d69ec2a200ed68c59bae5fae1115713a94c
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
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
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
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 allows the GLContextProviderWGL to be created on the compositor
thread, which is something we need for webrender integration.
MozReview-Commit-ID: DtBe9nUTdK7
--HG--
extra : rebase_source : b31973542beca75255b64f350f47df16435a60e3
The new names Create{,PreservingTransform}OrNull() better communicate that
these functions (a) do object creation, and (b) are fallible.
--HG--
extra : rebase_source : a36bd9a2bcdfae281868959403f811f2bc690ad4