SkNVRefCnt is a variant of SkRefCnt that's Not Virtual, so weighs 4 bytes
instead of 8 or 16. There's only benefit to doing this if the deriving class
does not otherwise need a vtable, e.g. SkPicture.
I've stripped out some cruft from SkPicture, rearranged fields to pack tightly,
and added compile asserts for the sizes of SkPicture, SkRecord, and
SkVarAlloc.
BUG=skia:3144
Review URL: https://codereview.chromium.org/741793002
When unique() returns true, it must also issue an acquire barrier.
Note that this change may adversly impact SkPath performance,
but editing SkPaths is already a performance issue.
BUG=chromium:258499
No API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/687293002
Example failure:
fRefCnt was 3
../../../usr/local/google/home/mtklein/skia/include/core/SkRefCnt.h:40: failed assertion "(fRefCnt == 1) || (SkDebugf("fRefCnt was %d""\n", fRefCnt), false)"
Command terminated by signal 11
Not pretty, but everything's there. Perhaps we'll think of ways to make it nicer later.
BUG=skia:
R=bsalomon@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/337243004
This is mostly s/public SkNoncopyable/SkNoncopyable/g.
Two classes (SkDrawLooper::Context and SkPicture::OperationList) don't actually work with SkNoncopyable because they introduce a virtual destructor. I added SkNoncopyableVirtual to make them work as intended. Sort of questionable whether they really need to be noncopyable in the first place, but I guess it doesn't hurt to keep the behavior the same.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/226183018
git-svn-id: http://skia.googlecode.com/svn/trunk@14081 2bbb7eff-a529-9590-31e7-b0007b416f81
Skia cannot use Chromium's implementation of mutex (Lock) due to static
initializers. However, we would like to be able to use Chromium's
implementation of atomics. This motivates the split of implementation.
Skia's atomic and mutex calls should be inlinable, especially the atomics.
These calls often compile down to very few instructions, and we currently have
the overhead of a function call. This motivates the header implementation.
There is still a desire for the build system to select the implementation, so
the SK_XXX_PLATFORM_H pattern for header files is introduced. This allows the
build system to control which platform specific header files are chosen.
The Chromium side changes (most of which will need to go in before this change
can be found at https://codereview.chromium.org/19477005/ .
The Chromium side changes after this lands can be seen at
https://codereview.chromium.org/98073013 .
Review URL: https://codereview.chromium.org/19808007
git-svn-id: http://skia.googlecode.com/svn/trunk@12738 2bbb7eff-a529-9590-31e7-b0007b416f81
std::shared_ptr has a method called 'unique' which captures the concept that
a reference count of 1 is special, and can be used to optimize copy on write.
It also has some undocumented need for memory barriers in certain situations
and those needs are documented here.
The motivation for looking into this is crbug.com/258499 . The use of the
reference count in this manner is a benign race with both ref() and unref().
By introducing sk_atomic_unprotected_read, it is possible for Chromium to
annotate this read to tell ThreadSanitizer that this is known.
R=bsalomon@google.com
Review URL: https://codereview.chromium.org/18770007
git-svn-id: http://skia.googlecode.com/svn/trunk@10221 2bbb7eff-a529-9590-31e7-b0007b416f81
smart pointers without need for another smart pointer type.
Note that the semantics of SkRefCnt match those WTF expects. In
particular, newly created objects have refcount 1 and objects are
deallocated at refcount 0.
This seems like a better fit than the AddRef/Release alises which exist
for scoped_ptr (but seem unused).
BUG=254509
R=reed@google.com
Author: jbroman@chromium.org
Review URL: https://chromiumcodereview.appspot.com/17880003
git-svn-id: http://skia.googlecode.com/svn/trunk@9784 2bbb7eff-a529-9590-31e7-b0007b416f81
https://codereview.chromium.org/13925021/
If a non-POD class does not provide a default destructor, one is
provided by teh compiler. GCC will do so, but only at the point where the
vtable is output; since BlockRef has no implementation its destructor is
never output, so there is no complaint. VC++, however, provides the
destructor implementation as soon as it sees the type. If the destructor
of BlockRef is ever defined an error will be reported (since the
destructor of SkData is private).
Declaring (but does not defining) a destructor for BlockRef fixes two
issues. First, it prevents a default destructor from being provided,
removing the VC++ error. Second, BlockRef now blocks access to the
destructor through '->'.
git-svn-id: http://skia.googlecode.com/svn/trunk@8697 2bbb7eff-a529-9590-31e7-b0007b416f81
I have manually examined all of these diffs and restored a few files that
seem to require manual adjustment.
The following files still need to be modified manually, in a separate CL:
android_sample/SampleApp/AndroidManifest.xml
android_sample/SampleApp/res/layout/layout.xml
android_sample/SampleApp/res/menu/sample.xml
android_sample/SampleApp/res/values/strings.xml
android_sample/SampleApp/src/com/skia/sampleapp/SampleApp.java
android_sample/SampleApp/src/com/skia/sampleapp/SampleView.java
experimental/CiCarbonSampleMain.c
experimental/CocoaDebugger/main.m
experimental/FileReaderApp/main.m
experimental/SimpleCocoaApp/main.m
experimental/iOSSampleApp/Shared/SkAlertPrompt.h
experimental/iOSSampleApp/Shared/SkAlertPrompt.m
experimental/iOSSampleApp/SkiOSSampleApp-Base.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Debug.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Release.xcconfig
gpu/src/android/GrGLDefaultInterface_android.cpp
gyp/common.gypi
gyp_skia
include/ports/SkHarfBuzzFont.h
include/views/SkOSWindow_wxwidgets.h
make.bat
make.py
src/opts/memset.arm.S
src/opts/memset16_neon.S
src/opts/memset32_neon.S
src/opts/opts_check_arm.cpp
src/ports/SkDebug_brew.cpp
src/ports/SkMemory_brew.cpp
src/ports/SkOSFile_brew.cpp
src/ports/SkXMLParser_empty.cpp
src/utils/ios/SkImageDecoder_iOS.mm
src/utils/ios/SkOSFile_iOS.mm
src/utils/ios/SkStream_NSData.mm
tests/FillPathTest.cpp
Review URL: http://codereview.appspot.com/4816058
git-svn-id: http://skia.googlecode.com/svn/trunk@1982 2bbb7eff-a529-9590-31e7-b0007b416f81
Add templated version of SkAutoTUnref.
Add unittests for it.
Remove unused helper apis on SkAutoUnref.
git-svn-id: http://skia.googlecode.com/svn/trunk@858 2bbb7eff-a529-9590-31e7-b0007b416f81
SkSafeRef() and SkSafeUnref().
This is basically a bug waiting to happen. An optimizing compiler can remove
checks for null on "this" if it chooses. However, SkRefCnt::safeRef() relies on
precisely this check...
void SkRefCnt::safeRef() {
if (this) {
this->ref();
}
}
Since a compiler might skip the if-clause, it breaks the intention of this
method, hence its removal.
static inline void SkSafeRef(SkRefCnt* obj) {
if (obj) {
obj->ref();
}
}
This form is not ignored by an optimizing compile, so we use it instead.
git-svn-id: http://skia.googlecode.com/svn/trunk@762 2bbb7eff-a529-9590-31e7-b0007b416f81
existing obj->safeRef(), which is unsafe since it can its 'if (this)' can be
optimized away by some compilers.
fix some overflows in mimpmap generation
git-svn-id: http://skia.googlecode.com/svn/trunk@181 2bbb7eff-a529-9590-31e7-b0007b416f81
