Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
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
I found invalidateCharacterCoordinates in NSTextInputContext. It's available 10.6 and later.
Calling this API does NOT make visible candidate window follow window move nor something to change layout, though. But we should call it.
MozReview-Commit-ID: KbllLDwlMOz
--HG--
extra : rebase_source : 175377bf7dd703dcd304ffbb8648e350080c07fc
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
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
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Invalidating a window's shadow is really slow and leads to flickering. Now that
arrow panels don't change their contents during the panel opening animation any
more, their shape stays the same after the first paint, so we don't need the
shadow invalidation functionality for them any more. And as far as I know, we
don't use transparent popups with changing shapes anywhere else.
The system still computes the shadow for the first paint of the window (which
happens during the orderFront call), and it updates the shadow whenever the
window resizes. But not when its size stays the same and only what we draw in
the content is updated.
MozReview-Commit-ID: 138PjbrSFrc
--HG--
extra : rebase_source : fed1c653ca3d88ef8b4e8e55a7d42b29e17a1624
Invalidating a window's shadow is really slow and leads to flickering. Now that
arrow panels don't change their contents during the panel opening animation any
more, their shape stays the same after the first paint, so we don't need the
shadow invalidation functionality for them any more. And as far as I know, we
don't use transparent popups with changing shapes anywhere else.
The system still computes the shadow for the first paint of the window (which
happens during the orderFront call), and it updates the shadow whenever the
window resizes. But not when its size stays the same and only what we draw in
the content is updated.
MozReview-Commit-ID: 138PjbrSFrc
--HG--
extra : rebase_source : fed1c653ca3d88ef8b4e8e55a7d42b29e17a1624
It appears that neither Chrome, Safari or Edge support this feature,
and it's causing web-compat issues for us, e.g. bug 1373417.
MozReview-Commit-ID: AP5LMgL6QmR
Extending it didn't play well with invalidation; widgets would only be able to
draw outside if the invalidated region of the current paint was larger than the
widget's declared paint rect but not if the widget was the only thing that got
invalidated.
Any legitimate widget overflow should instead be handled by GetWidgetOverflow.
The DrawCellWithSnapping overflow is considered to stay within the focus
ring's bounds.
I fuzzed two reftests which have extremely slight variance when -moz-appearance
is combined with box-shadow. I don't really understand this failure but I don't
think it's worth looking into either.
MozReview-Commit-ID: ECYxnCTafdh
--HG--
extra : rebase_source : 2cf9b21812347d18cd98cf3f1570b80074551d94
Wes Kocher
Ryan Hunt
Haik Aftandilian
Nicholas Nethercote
Josh Aas
Beekill95
Erica Wright
Kartikaya Gupta
Mats Palmgren
Carsten "Tomcat" Book
sotaro
Bill McCloskey
Masayuki Nakano
Markus Stange
Edgar Chen
Cameron McCormack
Alexis Beingessner
Sebastian Hengst