skia2/include/private/SkTDArray.h

382 lines
10 KiB
C
Raw Normal View History

/*
Automatic update of all copyright notices to reflect new license terms. 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
2011-07-28 14:26:00 +00:00
* Copyright 2006 The Android Open Source Project
*
Automatic update of all copyright notices to reflect new license terms. 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
2011-07-28 14:26:00 +00:00
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
Automatic update of all copyright notices to reflect new license terms. 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
2011-07-28 14:26:00 +00:00
#ifndef SkTDArray_DEFINED
#define SkTDArray_DEFINED
#include "SkMalloc.h"
#include "SkTo.h"
#include "SkTypes.h"
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
#include <utility>
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
template <typename T> class SkTDArray {
public:
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
SkTDArray() : fArray(nullptr), fReserve(0), fCount(0) {}
SkTDArray(const T src[], int count) {
SkASSERT(src || count == 0);
fReserve = fCount = 0;
fArray = nullptr;
if (count) {
fArray = (T*)sk_malloc_throw(count * sizeof(T));
memcpy(fArray, src, sizeof(T) * count);
fReserve = fCount = count;
}
}
SkTDArray(const SkTDArray<T>& src) : fArray(nullptr), fReserve(0), fCount(0) {
SkTDArray<T> tmp(src.fArray, src.fCount);
this->swap(tmp);
}
SkTDArray(SkTDArray<T>&& src) : fArray(nullptr), fReserve(0), fCount(0) {
this->swap(src);
}
~SkTDArray() {
sk_free(fArray);
}
SkTDArray<T>& operator=(const SkTDArray<T>& src) {
if (this != &src) {
if (src.fCount > fReserve) {
SkTDArray<T> tmp(src.fArray, src.fCount);
this->swap(tmp);
} else {
sk_careful_memcpy(fArray, src.fArray, sizeof(T) * src.fCount);
fCount = src.fCount;
}
}
return *this;
}
SkTDArray<T>& operator=(SkTDArray<T>&& src) {
if (this != &src) {
this->swap(src);
src.reset();
}
return *this;
}
friend bool operator==(const SkTDArray<T>& a, const SkTDArray<T>& b) {
return a.fCount == b.fCount &&
(a.fCount == 0 ||
!memcmp(a.fArray, b.fArray, a.fCount * sizeof(T)));
}
friend bool operator!=(const SkTDArray<T>& a, const SkTDArray<T>& b) {
return !(a == b);
}
void swap(SkTDArray<T>& that) {
using std::swap;
swap(fArray, that.fArray);
swap(fReserve, that.fReserve);
swap(fCount, that.fCount);
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
}
bool isEmpty() const { return fCount == 0; }
/**
* Return the number of elements in the array
*/
int count() const { return fCount; }
/**
* Return the total number of elements allocated.
* reserved() - count() gives you the number of elements you can add
* without causing an allocation.
*/
int reserved() const { return fReserve; }
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
/**
* return the number of bytes in the array: count * sizeof(T)
*/
size_t bytes() const { return fCount * sizeof(T); }
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T* begin() { return fArray; }
const T* begin() const { return fArray; }
T* end() { return fArray ? fArray + fCount : nullptr; }
const T* end() const { return fArray ? fArray + fCount : nullptr; }
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T& operator[](int index) {
SkASSERT(index < fCount);
return fArray[index];
}
const T& operator[](int index) const {
SkASSERT(index < fCount);
return fArray[index];
}
T& getAt(int index) {
return (*this)[index];
}
const T& getAt(int index) const {
return (*this)[index];
}
void reset() {
if (fArray) {
sk_free(fArray);
fArray = nullptr;
fReserve = fCount = 0;
} else {
SkASSERT(fReserve == 0 && fCount == 0);
}
}
void rewind() {
// same as setCount(0)
fCount = 0;
}
/**
* Sets the number of elements in the array.
* If the array does not have space for count elements, it will increase
* the storage allocated to some amount greater than that required.
* It will never shrink the storage.
*/
void setCount(int count) {
SkASSERT(count >= 0);
if (count > fReserve) {
this->resizeStorageToAtLeast(count);
}
fCount = count;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void setReserve(int reserve) {
SkASSERT(reserve >= 0);
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
if (reserve > fReserve) {
this->resizeStorageToAtLeast(reserve);
}
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T* prepend() {
this->adjustCount(1);
memmove(fArray + 1, fArray, (fCount - 1) * sizeof(T));
return fArray;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T* append() {
return this->append(1, nullptr);
}
T* append(int count, const T* src = nullptr) {
int oldCount = fCount;
if (count) {
SkASSERT(src == nullptr || fArray == nullptr ||
src + count <= fArray || fArray + oldCount <= src);
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
this->adjustCount(count);
if (src) {
memcpy(fArray + oldCount, src, sizeof(T) * count);
}
}
return fArray + oldCount;
}
T* appendClear() {
T* result = this->append();
*result = 0;
return result;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T* insert(int index) {
return this->insert(index, 1, nullptr);
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
T* insert(int index, int count, const T* src = nullptr) {
SkASSERT(count);
SkASSERT(index <= fCount);
size_t oldCount = fCount;
this->adjustCount(count);
T* dst = fArray + index;
memmove(dst + count, dst, sizeof(T) * (oldCount - index));
if (src) {
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
memcpy(dst, src, sizeof(T) * count);
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
return dst;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void remove(int index, int count = 1) {
SkASSERT(index + count <= fCount);
fCount = fCount - count;
memmove(fArray + index, fArray + index + count, sizeof(T) * (fCount - index));
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void removeShuffle(int index) {
SkASSERT(index < fCount);
int newCount = fCount - 1;
fCount = newCount;
if (index != newCount) {
memcpy(fArray + index, fArray + newCount, sizeof(T));
}
}
int find(const T& elem) const {
const T* iter = fArray;
const T* stop = fArray + fCount;
for (; iter < stop; iter++) {
if (*iter == elem) {
return SkToInt(iter - fArray);
}
}
return -1;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
int rfind(const T& elem) const {
const T* iter = fArray + fCount;
const T* stop = fArray;
while (iter > stop) {
if (*--iter == elem) {
return SkToInt(iter - stop);
}
}
return -1;
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
/**
* Returns true iff the array contains this element.
*/
bool contains(const T& elem) const {
return (this->find(elem) >= 0);
}
/**
* Copies up to max elements into dst. The number of items copied is
* capped by count - index. The actual number copied is returned.
*/
int copyRange(T* dst, int index, int max) const {
SkASSERT(max >= 0);
SkASSERT(!max || dst);
if (index >= fCount) {
return 0;
}
int count = SkMin32(max, fCount - index);
memcpy(dst, fArray + index, sizeof(T) * count);
return count;
}
void copy(T* dst) const {
this->copyRange(dst, 0, fCount);
}
// routines to treat the array like a stack
T* push() { return this->append(); }
void push(const T& elem) { *this->append() = elem; }
const T& top() const { return (*this)[fCount - 1]; }
T& top() { return (*this)[fCount - 1]; }
void pop(T* elem) { SkASSERT(fCount > 0); if (elem) *elem = (*this)[fCount - 1]; --fCount; }
void pop() { SkASSERT(fCount > 0); --fCount; }
void deleteAll() {
T* iter = fArray;
T* stop = fArray + fCount;
while (iter < stop) {
delete *iter;
iter += 1;
}
this->reset();
}
void freeAll() {
T* iter = fArray;
T* stop = fArray + fCount;
while (iter < stop) {
sk_free(*iter);
iter += 1;
}
this->reset();
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void unrefAll() {
T* iter = fArray;
T* stop = fArray + fCount;
while (iter < stop) {
(*iter)->unref();
iter += 1;
}
this->reset();
}
void safeUnrefAll() {
T* iter = fArray;
T* stop = fArray + fCount;
while (iter < stop) {
SkSafeUnref(*iter);
iter += 1;
}
this->reset();
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void visitAll(void visitor(T&)) {
T* stop = this->end();
for (T* curr = this->begin(); curr < stop; curr++) {
if (*curr) {
visitor(*curr);
}
}
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
#ifdef SK_DEBUG
void validate() const {
SkASSERT((fReserve == 0 && fArray == nullptr) ||
(fReserve > 0 && fArray != nullptr));
SkASSERT(fCount <= fReserve);
}
#endif
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
void shrinkToFit() {
fReserve = fCount;
fArray = (T*)sk_realloc_throw(fArray, fReserve * sizeof(T));
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
private:
T* fArray;
int fReserve;
int fCount;
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
/**
* Adjusts the number of elements in the array.
* This is the same as calling setCount(count() + delta).
*/
void adjustCount(int delta) {
SkASSERT(delta > 0);
// We take care to avoid overflow here.
// The sum of fCount and delta is at most 4294967294, which fits fine in uint32_t.
uint32_t count = (uint32_t)fCount + (uint32_t)delta;
SkASSERT_RELEASE( SkTFitsIn<int>(count) );
this->setCount(SkTo<int>(count));
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
}
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
/**
* Increase the storage allocation such that it can hold (fCount + extra)
* elements.
* It never shrinks the allocation, and it may increase the allocation by
* more than is strictly required, based on a private growth heuristic.
*
* note: does NOT modify fCount
*/
void resizeStorageToAtLeast(int count) {
SkASSERT(count > fReserve);
// We take care to avoid overflow here.
// The maximum value we can get for reserve here is 2684354563, which fits in uint32_t.
uint32_t reserve = (uint32_t)count + 4;
reserve += reserve / 4;
SkASSERT_RELEASE( SkTFitsIn<int>(reserve) );
fReserve = SkTo<int>(reserve);
Revert "implement SkTDArray with std::vector" This reverts commit 80e1d56e198c5fd9fe6db0c945bd558053a8dc6a. Reason for revert: SkRTree.cpp:57 asserting, probably this? Original change's description: > implement SkTDArray with std::vector > > It's always worth seeing if we can get away with replacing custom data > structures with ones from the standard library. Our array-like types > are all good candidates to replace with std::vector, and it's especially > easy to start with SkTDArray. Unlike the others, it has no preallocated > S-variant, which is tricky to make work with std::vector. > > SkTDArray also has known integer overflow bugs, leading to out of range > writes. It'd be _very_ nice to ditch it for a better standard vector. > > I removed a bunch of unused or little-used methods, and updated a couple > call sites that used methods in unusual or dangerous ways. > > I've had to tweak GrAAConvexTessellator and SkBaseShadowTessellator just > a touch to work within the constraints of an std::vector impl. It's not > intended to be legal to write to the reserved-but-not-counted elements > of an SkTDArray, but you can get away with it in our old implementation. > This version now uses setCount() to actually reserve and count them, and > should have the same performance and use the same amount of memory. > > The PathMeasure_explosion GM I added recently to reproduce this bug now > draws without triggering undefined behavior or ASAN errors, provided you > have ~40GB of RAM. > > Bug: skia:7674 > > Change-Id: I4eacae18a976cd4a6d218102f8ca5d973d4d7d0e > Reviewed-on: https://skia-review.googlesource.com/115982 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,bungeman@google.com,brianosman@google.com Change-Id: Icffd9f22fe89746a970ff598e1a05c774960bc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7674 Reviewed-on: https://skia-review.googlesource.com/117901 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
2018-04-02 20:37:42 +00:00
fArray = (T*)sk_realloc_throw(fArray, fReserve * sizeof(T));
}
};
template <typename T> static inline void swap(SkTDArray<T>& a, SkTDArray<T>& b) {
a.swap(b);
}
#endif