| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Also adds a presubmit to prevent adding trailing whitespace to source
code in the future.
Change-Id: I41a4df81487f6f00aa19b188f0cac6a3377efde6
Reviewed-on: https://skia-review.googlesource.com/57380
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
Ben Wagner
Florin Malita
scroggo
reed
scroggo