Before we begin re-arranging KeyframeEffect.h we move ComputedTiming aside
since putting it in a separate file should make navigating the source
easier.
MozReview-Commit-ID: L5GTFAo00sh
--HG--
extra : rebase_source : e88b6ea092c459afa90831de8469697454e00c5a
The former is only used inconsequentially in tests. The second is not used at
all.
--HG--
extra : rebase_source : 4cfe11f933f1fe8f788e823c5107941085cef92c
This reduces memory usage by up to 3 MiB per process.
MozReview-Commit-ID: Gfs9PIJM4br
--HG--
extra : rebase_source : 69ac5acf7f7f0c802a047f5bf72838e5c4d1f123
This was in a previously reviewed patch. I dropped the change because I
thought the underlying warning had been fixed. I was wrong.
MozReview-Commit-ID: J9B34YhJ3z0
--HG--
extra : source : ea446df75d17331a7c0736ef3303bf9a07d8d9f0
Wv:18 was added in bug 1119072 as a quick way to get the tree building
with VS2015. Now that we're closer to rolling out VS2015 support, we
want to expose its new warnings.
This patch replaces the blanket disabling of new warnings in VS2015 with
just disabling C5026 and C5027, which relate to symbols being implicitly
defined as deleted.
MozReview-Commit-ID: 8uniydfNJns
--HG--
extra : rebase_source : 5ca239cd20216e89115d1faeffc036b6eecb85ca
There are a long tail of C4311 and C4312 warnings in VS2015. Rather than
wait until all of them are fixed to land VS2015, we're taking the easy
way out and disabling these warnings in every directory currently
exhibiting a warning. This is evil. But it is a lesser evil than
globally disabling C4311 and C4312. At least with this approach new
C4311 and C4312 warnings in directories that aren't suppressing them
shouldn't be introduced.
MozReview-Commit-ID: 2cwWrjMD6B9
--HG--
extra : rebase_source : 3e7b8ea042765fdf138f5ca93a0f9dab75a95fcd
Without this, we get several warnings like:
reinterpret_cast': conversion from 'int32_t' to 'void *' of
greater size
MozReview-Commit-ID: sy2eTB2fjs
--HG--
extra : rebase_source : 16bd44fba1666c68c2fa163e57ed703eb0c823ed
extra : histedit_source : ea51ff0f6c2498d4ac87c50ede0ce70958d37a07
Without this, we get: C4312: 'reinterpret_cast': conversion from
'const LONG' to 'void *' of greater size
MozReview-Commit-ID: 4WXmvVUd5c8
--HG--
extra : rebase_source : 2f4211f4e752ef0ac2a1213075af6b62ecc8080f
extra : histedit_source : a1c91d27d8a97f141f07e89513262256104388ea
The fields in Prefable relating to disabling are usually all zero. This patch
moves them into a new struct PrefableDisablers. This reduces static data size
by 92 KB, which applies to every process. It might also make isEnabled() faster
because the common case only involves one test instead of two.
--HG--
extra : rebase_source : 004eb8221e23b741c4837dd95af93e437edb4587
This means that in RasterImage::LookupFrame when we are asked to do a sync decode (if needed) we use WaitUntilComplete to wait until the frame is finished decoding. But we would actually return after the next progressive pass notified the monitor to wake up. Thus, we would draw a not-fully-decoded image even though the sync decode flag was passed.
The change in FrameAnimator means that we won't draw the next frame in an animated image until all progressive passes of that image are complete. This seems like what we want anyways.
There is one real use of IsImageComplete left, in imgFrame::Draw, where we need to know if the decoded image data covers the whole image frame. (There are a couple of uses of IsImageComplete in asserts.)
@depends functions are declared like the following:
@depends('--option', other_function, '--other-option', ...)
def ...
To simplify some of the processing related to those arguments it's
passed, keep a tuple of Option and DummyFunction objects corresponding
to those arguments.
For the same reasons as set_config is being moved to the global scope,
we're moving set_define to the global scope here. An additional change
is that set_define is now part of the sandbox itself instead of being
defined within the sandbox, which makes it share the implementation
details with set_config.
The way set_config is set currently makes it difficult to introspect
moz.configure files to know what configuration items are being set,
because they're hidden in the control flow of functions.
This makes some of the moz.configure more convoluted, but this is why
there are templates, and we can improve the recurring cases afterwards.
Currently, ConfigureSandbox._db stores two different kind of
information. This split those in two different instance variables
instead, making things clearer.
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: BNhXxMhJaZh
--HG--
extra : rebase_source : 6d3746d99d0d058716a58f1ed1f0349e09866758
extra : source : cb49a303f86d6446bf1ed87d6e022e72a2ba25c7
Brian Birtles
Jonathan Watt
Nicholas Nethercote
Mike Hommey
Gregory Szorc
Matt Woodrow
Martin Thomson
Sotaro Ikeda
Heiher
Phil Ringnalda
Boris Zbarsky
Jeff Walden
Jeff Muizelaar
Kartikaya Gupta
Timothy Nikkel
Aaron Klotz