aboutsummaryrefslogtreecommitdiffhomepage
path: root/include/core/SkRWBuffer.h
Commit message (Collapse)AuthorAge
* Remove deprecated SkRWBuffer snapshot methodsGravatar Florin Malita2017-06-02
| | | | | | | Change-Id: I98fc6059fe74458fb359eaf00ccfcae50996a9e1 Reviewed-on: https://skia-review.googlesource.com/18480 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Add smartptr SkRWBuffer snapshot methodsGravatar Florin Malita2017-06-01
| | | | | | | Change-Id: Id816a38213a86bf090230ebaaef00d98a9487965 Reviewed-on: https://skia-review.googlesource.com/18266 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Florin Malita <fmalita@chromium.org>
* Add a SkRWBuffer reserve mechanismGravatar fmalita2016-09-30
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, Chromium stores segmented data in a SharedBuffer and appends to SkRWBuffer one segment at a time: const char* segment = 0; for (size_t length = data->getSomeData(segment, m_rwBuffer->size()); length; length = data->getSomeData(segment, m_rwBuffer->size())) { m_rwBuffer->append(segment, length, remaining); } This can yield a bunch of just-above-4k allocations => wasted RAM due to internal fragmentation. Ideally, we'd want a SkRWBuffer::reserve(size_t bytes) API, but the current internals don't support that trivially. Alternatively, the caller can pass a reserve hint at append() time. BUG=chromium:651698 R=scroggo@google.com,reed@google.com GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2385803002 Review-Url: https://codereview.chromium.org/2385803002
* Fixes for SkRWBufferGravatar scroggo2016-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | Do not call SkBufferHead::validate in SkROBuffer's destructor, which may be called in a separate thread from SkRWBuffer::append. validate() reads SkBufferBlock::fUsed, and append() writes to it, resulting in a data race. Update some comments to be more clear about how it is safe to use these classes across threads. Test the readers in separate threads. In addition, make sure it is safe to create a reader even when no data has been appended. Add tests for this case. Mark a parameter to SkBufferHead::validate() as const, reflecting its use. BUG=chromium:601578 BUG=chromium:605479 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1871953002 Review URL: https://codereview.chromium.org/1871953002
* Revert of Fixes for SkRWBuffer (patchset #5 id:80001 of ↵Gravatar bungeman2016-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1871953002/ ) Reason for revert: Making MSAN and TSAN rather unhappy. https://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-MSAN/builds/1586 https://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-TSAN/builds/5922 Original issue's description: > Fixes for SkRWBuffer > > Do not call SkBufferHead::validate in SkROBuffer's destructor, which > may be called in a separate thread from SkRWBuffer::append. validate() > reads SkBufferBlock::fUsed, and append() writes to it, resulting in > a data race. > > Update some comments to be more clear about how it is safe to use > these classes across threads. > > Test the readers in separate threads. > > In addition, make sure it is safe to create a reader even when no > data has been appended. Add tests for this case. > > Mark a parameter to SkBufferHead::validate() as const, reflecting > its use. > > BUG=chromium:601578 > GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1871953002 > > Committed: https://skia.googlesource.com/skia/+/d06920a29fe11c68bde2b93948ec99f277bb8459 TBR=mtklein@google.com,reed@google.com,scroggo@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:601578 Review URL: https://codereview.chromium.org/1882853004
* Fixes for SkRWBufferGravatar scroggo2016-04-14
| | | | | | | | | | | | | | | | | | | | | | | Do not call SkBufferHead::validate in SkROBuffer's destructor, which may be called in a separate thread from SkRWBuffer::append. validate() reads SkBufferBlock::fUsed, and append() writes to it, resulting in a data race. Update some comments to be more clear about how it is safe to use these classes across threads. Test the readers in separate threads. In addition, make sure it is safe to create a reader even when no data has been appended. Add tests for this case. Mark a parameter to SkBufferHead::validate() as const, reflecting its use. BUG=chromium:601578 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1871953002 Review URL: https://codereview.chromium.org/1871953002
* Fix race condition in SkROBuffer.Gravatar reed2016-04-08
| | | | | | | | | | SkBufferBlock::fUsed may be updated by the writer while a reader is attempting to read it. BUG=chromium:601578 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1872853002 Review URL: https://codereview.chromium.org/1872853002
* Add SK_API to SkROBuffer::IterGravatar scroggo2016-04-04
| | | | | | | | | | Necessary for crrev.com/1812273003 in Chromium. Also remove trailing whitespace. GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1856033002 Review URL: https://codereview.chromium.org/1856033002
* Move SkRWBuffer.h to include/ and add SK_APIGravatar scroggo2016-03-25
Needed for use in Blink in crrev.com/1812273003 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1838463003 Review URL: https://codereview.chromium.org/1838463003
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 03:45:21 +0000