Some memory allocators have very coarse size buckets, so for example on
Android (jemalloc) an attempt to allocate 32 KiB + 1 byte will end up
allocating 40 KiB, wasting 8 KiB.
GrMemoryPool ctor takes two arguments that specify prealloc / block sizes,
and then inflates them to accommodate some bookkeeping structures. Since
most places create GrMemoryPools with pow2 numbers (which have buckets in
most allocators) the inflation causes allocator to select next size bucket,
wasting memory.
This CL makes GrMemoryPool to stop inflating sizes it was created with, and
allocate specified amounts exactly. Part of allocated memory is then used for
bookkeeping structures. Additionally, GrObjectMemoryPool template is provided,
which takes prealloc / block object counts (instead of sizes) and guarantees
that specified number of objects will fit in prealloc / block spaces.
BUG=651872
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2525773002
Review-Url: https://codereview.chromium.org/2525773002
Replace with std::unique_ptr.
Change-Id: I5806cfbb30515fcb20e5e66ce13fb5f3b8728176
Reviewed-on: https://skia-review.googlesource.com/4381
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This code requires fewer macros to use it (just one), has less code in macro
definitions, and has simpler synchronization code (just atomic ints, no SkOnce,
no SkMutex, etc.)
A minor downside, we lose indentation and reverse-ordering in the final report:
Leaked SkRefCntBase: 7
Leaked SkFontMgr: 1
Leaked SkWeakRefCnt: 1
Leaked SkTypeface: 1
Leaked SkFlattenable: 3
Leaked SkXfermode: 3
Leaked SkPathRef: 1
Leaked SkPixelRef: 1
Leaked SkMallocPixelRef: 1
becomes
Leaked SkXfermode: 3
Leaked SkMallocPixelRef: 1
Leaked SkPixelRef: 1
Leaked SkPathRef: 1
Leaked SkFlattenable: 3
Leaked SkTypeface: 1
Leaked SkWeakRefCnt: 1
Leaked SkFontMgr: 1
Leaked SkRefCntBase: 7
This is motivated by wanting to land https://codereview.chromium.org/806473006/,
which makes sure all static use of SkOnce are in global scope. The current
implementation of SkInstCnt uses them in function scope, which isn't safe.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/841263004
Add INHERITED declarations to class declarations that prevent
compilation with the flag.
Remove SK_DEFINE_INST_COUNT from all class implementations. Instead,
use function-local static variables in the reference count helper
classes to create the global instances to store the needed info. The
accessor functions are defined inline in the helper classes, so
definitions are not needed. The initialization point of the variables
should be as well defined as previously.
Remove SK_DECLARE_INST_COUNT_TEMPLATE and use SK_DECLARE_INST_COUNT
instead. This avoids possible future compilation errors further.
For SK_ENABLE_INST_COUNT=0 compilation, add an empty static member
function to all classes that use SK_DECLARE_INST_COUNT and
SK_DECLARE_INST_COUNT_ROOT macros. The function ensures that classes
contain public INHERITED typedef. This member function seems to be
compiled away. This shouĺd ensure that part of the compilation errors
are caught earlier.
Also adds DSK_DECLARE_INST_COUNT to few SkPDFDict subclasses.
R=robertphillips@google.com, richardlin@chromium.org, bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/98703002
git-svn-id: http://skia.googlecode.com/svn/trunk@12501 2bbb7eff-a529-9590-31e7-b0007b416f81
unused headers and fixes a couple of bugs exposed by changing the random
number generator:
First, the function SkMatrix::getMaxStretch() had an error where it was testing
the square of a number against near-zero. This led to it occasionally taking a
cheaper but imprecise path for computing the eigenvalues of the matrix. It's
been replaced with a check against the square of SK_ScalarNearlyZero.
The second case was a failure in ClipStackTest, where it hit the rare case of
a practically empty clip stack (it has a single Union) and we set a tight
bounds. The bounds rect doesn't get set by GrReducedClip::ReduceClipStack() in
this case, so when it clips the reduced stack it's clipping against garbage,
and the resulting regions don't match. The solution is to initialize the
tightBounds rect.
git-svn-id: http://skia.googlecode.com/svn/trunk@7952 2bbb7eff-a529-9590-31e7-b0007b416f81