The shared memory handle reporting has been generalized to be an
external handle reporting. This is used for both shared memory, and for
volatile memory (on Android.) This will allow us to have a better sense
of just how many handles are being used by images on Android.
Additionally we were not properly reporting forced heap allocated
memory, if we were putting animated frames on the heap. This is because
we used SourceSurfaceAlignedRawData without implementing
AddSizeOfExcludingThis.
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
Currently if SourceSurfaceVolatileData::Map fails due to being purged,
we expect that the surface will be discarded by the caller. This has not
consistently been the case, and as such, we should ensure we do not
forget if a buffer was previously purged when we reacquire it. Since we
do not at this time support repopulating an already allocated buffer
with new data, we cannot reset this state once it has been set.
Currently if SourceSurfaceVolatileData::Map fails due to being purged,
we expect that the surface will be discarded by the caller. This has not
consistently been the case, and as such, we should ensure we do not
forget if a buffer was previously purged when we reacquire it. Since we
do not at this time support repopulating an already allocated buffer
with new data, we cannot reset this state once it has been set.
There have been reports of images remaining in the surface cache but no
longer containing the previously decoded data. Instead these appear as
transparent (BGRA) or black (BGRX). This suggests that somehow the image
surface buffer was reset to all zeroes. Additionally this seems to be
correlated with suspend and resume.
One possibility is that the OS purged our volatile buffers on suspend.
This is because we are supposed to be able to regenerate the contents
anyways, so it could choose to not preserve the data on suspend. In
general we should recover from this however and clearly we are not.
This patch adds a diagnostic assert to ensure that a buffer which was
previously purged is not reused later, as we should be discarding said
buffers.
