| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Change-Id: I6b08a74234b99bac866bad71014b94f7ec2d4bc8
Reviewed-on: https://skia-review.googlesource.com/10188
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
| |
This silences a new warning in clang 5.0
Change-Id: Ieb5b75a6ffed60107c3fd16075d2ecfd515b55e8
Reviewed-on: https://skia-review.googlesource.com/10006
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will be rolled out in three stages:
1) make SkMemory.h and have SkTypes.h include it.
2) Adjust chromium and android.
3) no long include SkMemory.h in SkTypes.h
Change-Id: If360ef5e1164d88f50b03f279e2e963ca2f57d5d
Reviewed-on: https://skia-review.googlesource.com/9874
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4492
Change-Id: I753ad01b03e891221965252e3befe280d09cdb9f
Reviewed-on: https://skia-review.googlesource.com/4492
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
We're currently ignoring the hint, resulting in multiple unneeded
allocations later.
BUG=chromium:651698
R=scroggo@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2384763002
Review-Url: https://codereview.chromium.org/2384763002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out function declarations don't end in semicolons...
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2720
No public API changes.
TBR=reed@google.com
Change-Id: I72b56d52e1ff7fa6e89c295b0de8c46599791ebb
Reviewed-on: https://skia-review.googlesource.com/2720
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
This enables removing the more complicated atomic shims from SkAtomics.h.
TBR=reed
This doesn't actually change any API.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot,Test-Ubuntu-GCC-Golo-GPU-GT610-x86_64-Release-TSAN-Trybot
Review URL: https://codereview.chromium.org/1867863002
|
|
|
|
|
|
|
|
|
|
|
| |
Check for NULL before calling unref.
Add a test.
BUG=483369
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1691383002
Review URL: https://codereview.chromium.org/1691383002
|
|
|
|
|
|
|
|
|
|
|
| |
According to the documentation, this method will return 0 when the Iter
is exhausted. Prior to this CL, it crashes instead.
Prevent a crash with a null fHead, and add a test to verify the
behavior.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1574603002
Review URL: https://codereview.chromium.org/1574603002
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316233002
Review URL: https://codereview.chromium.org/1316233002
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316123003
Review URL: https://codereview.chromium.org/1316123003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(and a couple presubmit fixes)
This allows us to turn back on -Werror for LLVM coverage builds,
and more generally supports building with Clang 3.7.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1232463006
|
|
WIP
- Can accumulate (write) data in one thread, and share snapshots of it in other threads
... e.g. network accumulates image data, and periodically we want to decode/draw it
- If this sort of thing sticks, should we promote SkData to have the same generality as
SkRBuffer?
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1106113002
|