- fill in a couple switches to allow software to rasterize gray8
- add a gray8 config to DM so we can test it
- enable this config on some bots
Today we draw gray8 using SkRasterPipeline, loading it as {g,g,g,1}
and storing using the same fixed luma math as SkLumaColorFilter.
One day it'd be nice to use the color space's luma vector if present.
Can we support this on GPU?
Change-Id: I4ee661c8bd5f33f5db2433ffb6e1bc2483af8397
Reviewed-on: https://skia-review.googlesource.com/92681
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I38736c5d49e3b281c2d23af3908575274ff97b5c
Reviewed-on: https://skia-review.googlesource.com/86282
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This is more consistent with our other SK_BUILD_FOR_... macros,
and less likely to collide with other preprocessor logic.
(Luckily, this was defined in public.bzl, so we can do this
all in one CL in the Skia repo.)
Change-Id: I5f232888288c9c53fad445545d983d0fb0b4add8
Reviewed-on: https://skia-review.googlesource.com/86940
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Add a real implementation for gm_knowledge.h This depends on
the presence of files in the form $GMK_DIR/foo/{max,min}.png
The implementation also writes out failures in a report directory.
Add a utility: experimental/make_gmkb which is a stand-alone
go executable that generates the foo/{max,min}.png data.
tools/skqp/README.md has instructions on running SkQP.
Also: add SkFontMgrPriv.h
Change-Id: Ibe1e9a7e7de143d14eee3877f5f2d2d8713f7f49
Reviewed-on: https://skia-review.googlesource.com/65380
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Some pieces still remain, but the next step looks less mechanical,
so I wanted to land this piece independently.
Bug: skia:
Change-Id: Ie63afcfa08af2f6e4996911fa2225c43441dbfb2
Reviewed-on: https://skia-review.googlesource.com/84120
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit cca2300559.
Reason for revert: think I guessed wrong about g32 -- unreverting
Original change's description:
> Revert "resources: remove most uses of GetResourcePath()"
>
> This reverts commit 5093a539de.
>
> Reason for revert: google3 seems broken
>
> Original change's description:
> > resources: remove most uses of GetResourcePath()
> >
> > Going forward, we will standardize on GetResourceAsData(), which will
> > make it easier to run tests in environments without access to the
> > filesystem.
> >
> > Also: GetResourceAsData() complains when a resource is missing.
> > This is usually an error.
> >
> > Change-Id: Iaf70b71b0ca5ed8cd1a5538a60ef185ae8736188
> > Reviewed-on: https://skia-review.googlesource.com/82642
> > Reviewed-by: Hal Canary <halcanary@google.com>
> > Commit-Queue: Hal Canary <halcanary@google.com>
>
> TBR=halcanary@google.com,scroggo@google.com
>
> Change-Id: Ic5a7c0167c995a672e6b06dc92abe00564432214
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/83001
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=halcanary@google.com,scroggo@google.com,reed@google.com
Change-Id: I5a46e4de61186a8a5eb9cacd3275e24e311d5a07
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/82942
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit 5093a539de.
Reason for revert: google3 seems broken
Original change's description:
> resources: remove most uses of GetResourcePath()
>
> Going forward, we will standardize on GetResourceAsData(), which will
> make it easier to run tests in environments without access to the
> filesystem.
>
> Also: GetResourceAsData() complains when a resource is missing.
> This is usually an error.
>
> Change-Id: Iaf70b71b0ca5ed8cd1a5538a60ef185ae8736188
> Reviewed-on: https://skia-review.googlesource.com/82642
> Reviewed-by: Hal Canary <halcanary@google.com>
> Commit-Queue: Hal Canary <halcanary@google.com>
TBR=halcanary@google.com,scroggo@google.com
Change-Id: Ic5a7c0167c995a672e6b06dc92abe00564432214
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/83001
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Going forward, we will standardize on GetResourceAsData(), which will
make it easier to run tests in environments without access to the
filesystem.
Also: GetResourceAsData() complains when a resource is missing.
This is usually an error.
Change-Id: Iaf70b71b0ca5ed8cd1a5538a60ef185ae8736188
Reviewed-on: https://skia-review.googlesource.com/82642
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Should make it easier to ask just for images.
Change-Id: If821743dc924c4bfbc6b2b2d29b14affde7b3afd
Reviewed-on: https://skia-review.googlesource.com/82684
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
This partially reverts commit
1793e7bb46.
Hide SkEncodedInfo
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, make SkAndroidCodec a friend so it can
access the SkEncodedInfo. A future change will change SkCodec to
recommend F16 for bitsPerComponent > 8, but that will be more involved;
it was the reason for the revert of this CL.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
TBR=mtklein@chromium.org,reed@google.com
Change-Id: I928b1f55317602cb37d29da63b53026c8d139cee
Reviewed-on: https://skia-review.googlesource.com/80860
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit c6f7a4ffa9.
Reason for revert: Causing differences in Gold, stemming from the fact that this changes the recommended SkImageInfo for 16 bits-per-component PNG from N32 to F16.
- an F16 bitmap already png-encodes to a 16 bits-per-component PNG, but it does not encode a linear colorspace (possibly a bug?). when we decode this PNG using getInfo(), it fails because it has an F16 color type and non-linear colorspace. (In the encode-srgb-png gm, this results in blank results for F16.) We could correct this on the encoder side, but it seems possible that a 16 bits-per-component PNG could be encoded with a different color space. In that case, we'd want SkCodec to recommend F16/SRGBLinear, but I think we'd want the SkCodec to store the encoded SkColorSpace so that we can Xform between the two. Currently SkCodec only stores one color space, so that will require a refactor.
- When decoding 16-bits-per-component PNGs, we are now decoding them to F16. This shows differences in Gold. The srgb/gpu results now look more like F16. I think this is fine.
Original change's description:
> Hide SkEncodedInfo
>
> Bug: skia:7353
> Bug: skia:6839
>
> This contains information that is not necessary for clients to know. The
> Color enum tells the number of components in the input, but this is only
> interesting internally (to the SkSwizzler).
>
> Similarly, the Alpha enum differs from SkAlphaType in that it has
> kBinary instead of kPremul. This is useful information only internally
> for determining whether the SkColorSpaceXform needs to premultiply.
>
> The bitsPerComponent is potentially useful for a client; Android (in
> SkAndroidCodec) uses it to determine the SkColorType. Rather than
> exposing bitsPerComponent, use it to make the same decision that Android
> would have made - 16 bits per component means to set the info to F16. Add
> a test that computeOutputColorType behaves as expected.
>
> Switch conversionSupported to use an SkColorType, which is enough info.
>
> Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
> SkAlphaType.
>
> SkCodec still needs an SkEncodedInfo, so move its header (which is
> already not SK_API) to include/private.
>
> Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
> Reviewed-on: https://skia-review.googlesource.com/79260
> Reviewed-by: Mike Reed <reed@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Leon Scroggins <scroggo@google.com>
TBR=mtklein@chromium.org,scroggo@google.com,reed@google.com
Change-Id: I0c5dd1461e1b70d1e55349a8e7ee6b029c3f556e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7353, skia:6839
Reviewed-on: https://skia-review.googlesource.com/80660
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, use it to make the same decision that Android
would have made - 16 bits per component means to set the info to F16. Add
a test that computeOutputColorType behaves as expected.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
Reviewed-on: https://skia-review.googlesource.com/79260
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
To our knowledge it's not used.
Its defer- mode in DM isn't even run on the bots.
Change-Id: Ifebfa2a77bfed8370eb421d379697f04fa2c8608
Reviewed-on: https://skia-review.googlesource.com/76420
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is to alleviate problems due to the command buffer getting bent out of shape when the current
OpenGL context is switched out from under it (because we ran a test with a native GL context). This,
however is not a full solution. More changes will be required to ensure that after running each
command buffer or native test we bind the null context. This does allow us to take a step in that
direction without breaking anything too badly. Moreover, there is no real benefit to reusing a
GrContextFactory.
Modifies DEF_GPUTEST to take GrContextOptions rather than a factory to use. Tests were already using
their own factories anyway.
In tests that use GrContextFactory the factory instance is moved to the inner loop.
Modifies gpucts and skia_test to not use persistent GrContextFactories.
Change-Id: Ie7a36793545c775f2f30653ead6fec93a3d22717
Reviewed-on: https://skia-review.googlesource.com/71861
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This is a utility that creates a version of an existing XYZ color space
that performs our color spin operation. Assigning this to a source remaps
RGB to GBR. Assigning it to a destination does the opposite (RGB to BRG).
Bug: skia:
Change-Id: I3528698220bd32aa01dcd3db225e60f151a4b5bd
Reviewed-on: https://skia-review.googlesource.com/71280
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Change-Id: I4dc745479ceb1d5ca1ddb4a0904f342576e4562c
Reviewed-on: https://skia-review.googlesource.com/71240
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Hal Canary <halcanary@google.com>
- Replace build-time GDI support in all of Skia
with run-time GDI support only in DM.
- Make the GDI bots NativeFont bots paralelling
the other NativeFonts bots.
Change-Id: I424b20f6983d8a8ba8574650efefea2b8776bbe2
Reviewed-on: https://skia-review.googlesource.com/70721
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
- return nullptr for the various makeFromFoo() that we can't support,
and tweak a few unit tests to bail out early when they do
- create FontStyleSet and SkTypefaces once
- abort early from FontHostStream if we can't openStream()
- implement SkTestTypeface::onCreateFamilyNameIterator()
with SkOTUtils::LocalizedStrings_SingleName() so FontNames passes
- pin out-of-range glyph IDs to zero in SkTestTypeface
Change-Id: Iac53265e331fc1c5c507513af3ab299063e6610a
Reviewed-on: https://skia-review.googlesource.com/69501
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Controlled by --[no]nativeFonts, and still defaults to native fonts.
Change-Id: Ib2879e69fadb63ddb5a17a7e4ae227941893b8cf
Reviewed-on: https://skia-review.googlesource.com/67806
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
SkImageGeneratorCG:
- Detect the origin and apply it to the output
- Deprecate NewFromEncodedCG and add MakeFromEncodedCG
SkCodecImageGenerator:
- Move code elsewhere for sharing
- Apply origin for incomplete decodes
SkPixmap.cpp/SkPixmapPriv.h:
- Now has the shared code for generators to apply origin
DMSrcSink.cpp:
- Call MakeFromEncodedCG
SkCGUtils.h:
- Add a version of SkCopyPixelsFromCGImage that takes an SkPixmap
Bug: skia:7138
Bug: skia:3834
Change-Id: Ic6dbc76360c6a84913b67373582f328d3946d637
Reviewed-on: https://skia-review.googlesource.com/63740
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This allows the via to work with GPU (where we don't render to N32).
Change-Id: I42e8457731a5ee51d14f7092eebd6efe72decd84
Reviewed-on: https://skia-review.googlesource.com/65822
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 5b9a037bf4.
Reason for revert:
I got confused in here somewhere and everything is drawing wrong.
Original change's description:
> gbr- has been brg- this whole time...
>
> Rewrite things to make that a little clearer.
>
> A red pixel ends up in channel 2, what would naively draw as blue
> without a rotation. A green pixel ends up in channel 0, which would
> naively draw as red without rotation. A blue pixel ends up in channel
> 1, which would naively draw as green without this rotation.
>
> So this transformation is:
>
> r -> b
> g -> r
> b -> g
>
> i.e. rgb_to_brg
>
> Change-Id: I12331ff2622194e34a44f421f656fbe4db5d3dca
> Reviewed-on: https://skia-review.googlesource.com/65521
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@chromium.org,brianosman@google.com
Change-Id: Ib29800b242bf736b20d61375d3c437c8f4ffdce0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/65781
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Rewrite things to make that a little clearer.
A red pixel ends up in channel 2, what would naively draw as blue
without a rotation. A green pixel ends up in channel 0, which would
naively draw as red without rotation. A blue pixel ends up in channel
1, which would naively draw as green without this rotation.
So this transformation is:
r -> b
g -> r
b -> g
i.e. rgb_to_brg
Change-Id: I12331ff2622194e34a44f421f656fbe4db5d3dca
Reviewed-on: https://skia-review.googlesource.com/65521
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Ic9e6cfe82dd22ac01be7a51724efa4c00399cfef
Reviewed-on: https://skia-review.googlesource.com/65320
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I871dd5eea4496e87c206b46d9eae81cb521b11ce
Reviewed-on: https://skia-review.googlesource.com/65103
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Adds the flag and a disables caching on the CCPR bots.
Bug: skia:
Change-Id: Icb85e77f89634dda1d419dacac5b8a93340723f0
Reviewed-on: https://skia-review.googlesource.com/59740
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This reverts commit 454818b80a.
Reason for revert: the GPU unit tests on Chromebook that this change enabled are not surprisingly broken.
Original change's description:
> Attempt both GL and GLES for GPU unit tests
>
> The hardcoded logic was not all inclusive and caused Chromebooks to
> not run GPU unit tests.
>
> Bug: skia:
> Change-Id: I7688adab314d12234ee03363609a1c4bf8f2edb5
> Reviewed-on: https://skia-review.googlesource.com/55561
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
TBR=bsalomon@google.com,brianosman@google.com,csmartdalton@google.com
Change-Id: I48a6fdf0b21d3f3a795d9cf20564208f7c35ff5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/55960
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
The hardcoded logic was not all inclusive and caused Chromebooks to
not run GPU unit tests.
Bug: skia:
Change-Id: I7688adab314d12234ee03363609a1c4bf8f2edb5
Reviewed-on: https://skia-review.googlesource.com/55561
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This reverts commit 88757dacd4.
Reason for revert: Still seems to be failing Chromium "telemetry_perf_unittests (with patch) on Android" on android_n5x_swarming_rel.
Original change's description:
> guard old apis for querying byte-size of a bitmap/imageinfo/pixmap
>
> Now with legacy behavior for allocpixels
>
> This was reverted, so the current CL is a "fix" on top of ...
> https://skia-review.googlesource.com/c/skia/+/50980
>
> Related update to Chrome (in preparation for this change)
> https://chromium-review.googlesource.com/c/chromium/src/+/685719
>
> Bug: skia:
> Change-Id: I4b370ee7e95083ab27421f008132219c9c7b86e9
> Reviewed-on: https://skia-review.googlesource.com/51341
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=fmalita@chromium.org,reed@google.com
Change-Id: I827a0ca1d1e3909e648fde3342cdb8601d34da8d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/52381
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This reverts commit 98a6216b18.
Reason for revert: breaking the chrome roll. Looks like they may be writing data to create an image across all the row bytes and thus writing to unalloced data on the last row. Link to example failing bot:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/539960
Original change's description:
> guard old apis for querying byte-size of a bitmap/imageinfo/pixmap
>
> Previously we had size_t and uint64_t variations.
>
> The new (simpler) API always..
> - returns size_t, or 0 if the calculation overflowed
> - returns the trimmed size (does not include rowBytes padding for the last row)
>
> Bug: skia:
> Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e
> Reviewed-on: https://skia-review.googlesource.com/50980
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Reviewed-by: Leon Scroggins <scroggo@google.com>
TBR=mtklein@google.com,herb@google.com,scroggo@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I726f6ab1b36b14979ba6f37105e0a469b3f0dbc0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/51262
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Previously we had size_t and uint64_t variations.
The new (simpler) API always..
- returns size_t, or 0 if the calculation overflowed
- returns the trimmed size (does not include rowBytes padding for the last row)
Bug: skia:
Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e
Reviewed-on: https://skia-review.googlesource.com/50980
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Removes SkString-related malloc from DM crash handler, and adds null check in ProxyRefTest.
Bug: skia:3550
Change-Id: I143c532b5d231a426b1a96b854e1effd6379b673
Reviewed-on: https://skia-review.googlesource.com/48440
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
As DAA does not chop edges at Y extrema, it's valid for convex edges to
have only one edge (e.g., a single cubic edge with the valley shape \_/).
This wasn't an issue for production because DAA is never called for
convex paths by default.
Bug=skia:7015
Change-Id: Iac79801d6a24188970ef6f7bf723494a25d92a1e
Reviewed-on: https://skia-review.googlesource.com/42942
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
For configs that compare results of two drawing methods, it's helpful to
know how the two images differed. This takes both images, PNG encodes them
(at maximum compression settings), then base64 encodes them into data URIs
so they can be viewed directly from the logs.
These kinds of failures are typically very rare, and currently happen
infrequently due to flaky GMs - we don't want to be using this kind of
facility all the time.
Bug: skia:7011
Change-Id: Ib6c271cb8f6cd657cf6ca8ccfee97d0193b4e6ed
Reviewed-on: https://skia-review.googlesource.com/43240
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@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>
