| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
To fix gm/bigrect, needed to do adjust "largest" rect so it doesn't become empty when round-tripping with SkRect/SkIRect.
I renamed it after this.
Bug: skia:
Change-Id: I747782c8456da603cf298275d2300ea1996e7629
Reviewed-on: https://skia-review.googlesource.com/95563
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, transformedBounds is finite but its rounded out
IRect is empty so we can't do that.
TBR: reed@google.com
Bug: skia:
Change-Id: Ife78e91a494964042fa09b8cbe86cabbd2572fb9
Reviewed-on: https://skia-review.googlesource.com/92625
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a smaller CL distilled from our init-once CL (87784).
Note that the thread alloc is unused here but it will be used by
init-once.
Bug: skia:
Change-Id: If4bc2febfb3fbcd85bf973a01e60b9b64c873a19
Reviewed-on: https://skia-review.googlesource.com/92621
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
| |
Related to https://skia-review.googlesource.com/c/skia/+/91860
Bug: skia:
Change-Id: Ia8fd981b422bbab75541b078277d2e09e1fc9d41
Reviewed-on: https://skia-review.googlesource.com/91940
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is identical to 70221 except for 3 lines inside SkFlexibleTaskGroup2D::work
to bypass the false-positive warning. We cannot reproduce the error the android
roller generated so we'll have to try and see.
The detailed warning can be found in:
https://skia-review.googlesource.com/c/skia/+/78720
TBR: mtklein@google.com
Bug: skia:
Change-Id: I3e2f414581dbd1398482cf45cf4f43eaf0535651
Reviewed-on: https://skia-review.googlesource.com/79321
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 07a42411f8d4a00d992bafdd18f2183f58c4547a.
Reason for revert: This looks to be breaking the Android roll. See https://googleplex-android-review.googlesource.com/c/platform/external/skia/+/3295488
external/skia/src/core/SkTaskGroup2D.cpp:73:28: error: releasing mutex 'rowData.fMutex' that was not held [-Werror,-Wthread-safety-analysis]
rowData.fMutex.unlock();
Original change's description:
> Renaming and refactoring to prepare for init-once threaded backend
>
> Bug: skia:
> Change-Id: I39b1d73b612a9c133847dd7361d634a0351659f1
> Reviewed-on: https://skia-review.googlesource.com/70221
> Reviewed-by: Herb Derby <herb@google.com>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
TBR=mtklein@google.com,herb@google.com,liyuqian@google.com
Change-Id: I701e6c62f6f437a6a285953b45b2e58cf7f0b6e5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/78720
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
|
|
|
|
|
|
|
|
| |
Bug: skia:
Change-Id: I39b1d73b612a9c133847dd7361d634a0351659f1
Reviewed-on: https://skia-review.googlesource.com/70221
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We like a LIFO default thread pool in tools like DM for better
memory/time locality... the bots use less memory this way, and
generally run faster.
But most use cases want a FIFO queue, so that they can get going
on the next parts of early work while later work is still running.
This splits the implementation into one using SkTArray and pop_back
for LIFO, and a new one using std::deque and pop_front for FIFO.
Change-Id: Ief203b6869a00f1f8084019431a781d15fc63750
Reviewed-on: https://skia-review.googlesource.com/41849
Commit-Queue: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
So that callers could manage the thread pool themselves instead of
relying on SkThreadBMPDevice.
Bug: skia:
Change-Id: Idbeafc9ac5d111370fd1b74f6eab9ac8df179940
Reviewed-on: https://skia-review.googlesource.com/39760
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Our SkThreadedBMPDevice is very experimental so I didn't handle this
edge case earlier. Maybe it's now a good time to fix it.
Bug: skia:
Change-Id: Ie3938475449c1341d34200ff3afe4589836950fc
Reviewed-on: https://skia-review.googlesource.com/31203
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Yuqian Li <liyuqian@google.com>
|
|
|
|
|
|
|
|
|
| |
Motivation: a simpler call should make it easier for SkPDF to learn how
to do drawBitmap with A8 bitmap and a maskfilter.
Change-Id: I1a5d190b40b0e9e08fa8876d265a9835a3e9987d
Reviewed-on: https://skia-review.googlesource.com/20961
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
|
|
|
|
|
|
|
|
|
| |
clang-tidy pointed out this opportunity in the Google3 build.
Change-Id: Id3c7b291fec12cbf860e7fc2583c1a34ad23f697
Reviewed-on: https://skia-review.googlesource.com/18927
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(instead of finishing enque before draw). The highlight is that we can now
achieve 9x speedup compared to 5x in all our previous approaches
(including multi-picture draw).
The schedulers here are experimental. I'd like to move on to try initializing
once for each draw before further polishing and optimizing the schedule
mechanism.
Bug: skia:
Change-Id: Idc3d030d475af9645c24c5372ff62b9a402206cc
Reviewed-on: https://skia-review.googlesource.com/17826
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
|
|
BUG=skia:
Change-Id: I882b6563c735796f3a4dcd19f6c79e7efd8306ae
Reviewed-on: https://skia-review.googlesource.com/10505
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|