Many tests and examples use drawText with
a guess of how long the text is in bytes,
or a call to strlen(). Add a helper to
SkCanvas to simplify these examples.
Add another helper for SkString.
R=reed@google.com
Change-Id: I0204a31e938f065606f08ee7cd9a6b36db791ee2
Reviewed-on: https://skia-review.googlesource.com/13642
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@skia.org>
We will re-enable once the proxy instantiation is moved past the TextureSamplers
Bug: 715488
Change-Id: I4f0dee18fc191d7fffb6a2f4fedd825729ebb057
Reviewed-on: https://skia-review.googlesource.com/14520
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit d4a338f4d0.
Reason for revert: Looks like I missed something I was supposed to delete in Android.
Original change's description:
> Delete copyTo(Allocator), hide copyTo() behind flag
>
> Replace uses of copyTo() in Skia.
>
> Bug: skia:6464
> Change-Id: I921dc53a1c29a5176d18f05741f7c0b5a008e548
> Reviewed-on: https://skia-review.googlesource.com/14502
> Commit-Queue: Matt Sarett <msarett@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
>
TBR=msarett@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I4d252940cc6a2462b030007055ea6c229471fc6e
Reviewed-on: https://skia-review.googlesource.com/14602
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This reverts commit fdd77daedb.
Reason for revert: Apparently I have a few more build files to update before this can land.
Original change's description:
> Plumb the use of GrBackendRenderTarget throughout Skia
>
> Bug: skia:
> Change-Id: Ib99a58d9552f5c7b8d77c09dcc72fa88326c26aa
> Reviewed-on: https://skia-review.googlesource.com/14148
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I984e1909870182474c4c3cce257f01b6a9d8581f
Reviewed-on: https://skia-review.googlesource.com/14531
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Replace uses of copyTo() in Skia.
Bug: skia:6464
Change-Id: I921dc53a1c29a5176d18f05741f7c0b5a008e548
Reviewed-on: https://skia-review.googlesource.com/14502
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
We were allocating a local bitmap, but then attempting to read into an
uninitialized local pixmap. The only public API that funnels the caching
hint to this function is scalePixels, so I added a test (which previously
failed).
Bug: skia:
Change-Id: Ib4370350be664935b4c85e34c70b675e6d82ba64
Reviewed-on: https://skia-review.googlesource.com/14402
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
In this case, the fuzzer thinks there is a bug because we are
returning kInvalidConversion for a corrupt png file.
Bug: skia:6550
Change-Id: I33f588442f5eaa8a4d642e9328750779f9a9ef5d
Reviewed-on: https://skia-review.googlesource.com/14324
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
The parametric_{r,g,b} stages are just as good now;
under the hood it's all going through approx_powf.
Change-Id: If7f3ae1e24fcee2ddb201c1d66ce1dd64820c89a
Reviewed-on: https://skia-review.googlesource.com/14320
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This wasn't seen locally b.c. it is an assert and I only ran release locally and the CQ also only runs release.
I have added linux_trusty_blink_dbg as a try job.
TBR=bsalomon@google.com
Bug: 715392
Change-Id: I010626cb97e886d2fbfd767f948bc640f0534338
Reviewed-on: https://skia-review.googlesource.com/14361
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Adjusted unit test to verify this behavior.
Bug: skia:6547 chromium:713632 chromium:713702
Change-Id: I6240937b2faf6ccb6adfc9477dc85ae961cdbbb7
Reviewed-on: https://skia-review.googlesource.com/14279
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
* Use unique_ptr, sk_sp, SkAutoFree, using.
* Rely on thread-safe static global initializion.
Change-Id: I7c14e0e57622163b1b81b97a218b816fe6d02926
Reviewed-on: https://skia-review.googlesource.com/13818
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Better imitate the original Android bug. Create a stream with
multiple images in it, and verify that it successfully decodes after
decoding once.
This exposes a bug in SkPngCodec, which did not work for interlaced
images.
Test more formats that also happen to succeed: ICO, BMP, and WBMP
This explicitly does *not* attempt to fix sampled or subset
decodes, which already stopped early when decoding as an
optimization.
Change-Id: Ib0b8918f14ba3fb0fa31e9c71c8100dcbeeb465f
Reviewed-on: https://skia-review.googlesource.com/14104
Reviewed-by: Matt Sarett <msarett@google.com>
This reverts commit df2bf21364.
Reason for revert: Maybe AndroidOne timing out
Original change's description:
> Split up opLists (take 2)
>
> Reland of: https://skia-review.googlesource.com/c/11581/ (Split up opLists)
>
> https://skia-review.googlesource.com/c/13860/ (Make InstancedRendering more opList-splitting friendly) has landed so this should be good for another attempt.
>
> Change-Id: Icc9998196587510328e0a9ca1b2ce42013a86c6c
> Reviewed-on: https://skia-review.googlesource.com/13802
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I744f2a3145b294e5911862bb39d57ca33a1b9a5a
Reviewed-on: https://skia-review.googlesource.com/14184
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
If process_data is unable to read (and therefore process) as many bytes
as it expects, process the bytes read before returning false.
Fixes differences in Gold.
Add a test that verifies that it is okay to call png_process_data with
0 bytes. (We could special case 0, but libpng already checks for 0.)
Change-Id: Id500b9305ee3bb6a1a7e8fc70d4e723cb4742b55
Reviewed-on: https://skia-review.googlesource.com/14144
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
(Originally uploaded as 13900.)
Previously, SkPngCodec assumed that the stream only contained one
image, which ended at the end of the stream. It read the stream in
arbitrarily-sized chunks, and then passed that data to libpng for
processing.
If a stream contains more than one image, this may result in reading
beyond the end of the image, making future reads read the wrong data.
Now, SkPngCodec starts by reading 8 bytes at a time. After the
signature, 8 bytes is enough to know which chunk is next and how many
bytes are in the chunk.
When decoding the size, we stop when we reach IDAT, and when decoding
the image, we stop when we reach IEND.
This manual parsing is necessary to support APNG, which is planned in
the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
was a workaround for reading more than necessary at the beginning of
the image.
Add a test that simulates the issue, by decoding a special stream that
reports an error if the codec attempts to read beyond the end.
Temporarily disable the partial decoding tests for png. A larger change
will be necessary to get those working again, and no clients are
currently relying on incrementally decoding PNGs (i.e. decode part of
an image, then decode further with more data).
Include a workaround for older versions of libpng (e.g. 1.2 in
Google3). In older versions, if the row callback is null when the
IDAT header is processed, reading the image will fail. When we see the
IDAT, we save the length and process a recreated IDAT header later,
after the row callback has been set.
Bug: skia:5368
Bug:b/34073812
Test: Existing tests, plus a new test in dm.
Change-Id: I293a4ddc013b82669a8b735062228b26d0bce933
Reviewed-on: https://skia-review.googlesource.com/13984
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
My main interest is getting rid of weird code, but it's also faster.
The new bench drops from 667 to 412.
Change-Id: Ibf889601284cf925780320c828394f79937dc705
Reviewed-on: https://skia-review.googlesource.com/14035
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 02242e82e4.
Reason for revert: Maybe breaking Chrome DEPS roll
Original change's description:
> Rm makeRenderTargetContext in favor of deferred version (take 2)
>
> This is a reland of: https://skia-review.googlesource.com/c/13001/ (Rm makeRenderTargetContext in favor of deferred version)
>
> Change-Id: Ife77b012d09c46895884a168fc5045bd92a4b919
> Reviewed-on: https://skia-review.googlesource.com/13196
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2607116ed743f5d313da4a7b7f056776ed907702
Reviewed-on: https://skia-review.googlesource.com/14024
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 2c65d51612.
Reason for revert: Causing failures in Google3 (https://test.corp.google.com/ui#cl=153703311&flags=CAMQAg==&id=OCL:153703311:BASE:153703364:1492695824938:4db2240d&t=//chrome/skia/dm_wrapper:dm_wrapper) and differences in Gold. This change was not intended to change the output.
Original change's description:
> Make SkPngCodec only read as much of the stream as necessary
>
> Previously, SkPngCodec assumed that the stream only contained one
> image, which ended at the end of the stream. It read the stream in
> arbitrarily-sized chunks, and then passed that data to libpng for
> processing.
>
> If a stream contains more than one image, this may result in reading
> beyond the end of the image, making future reads read the wrong data.
>
> Now, SkPngCodec starts by reading 8 bytes at a time. After the
> signature, 8 bytes is enough to know which chunk is next and how many
> bytes are in the chunk.
>
> When decoding the size, we stop when we reach IDAT, and when decoding
> the image, we stop when we reach IEND.
>
> This manual parsing is necessary to support APNG, which is planned in
> the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
> was a workaround for reading more than necessary at the beginning of
> the image.
>
> Add a test that simulates the issue, by decoding a special stream that
> reports an error if the codec attempts to read beyond the end.
>
> Temporarily disable the partial decoding tests for png. A larger change
> will be necessary to get those working again, and no clients are
> currently relying on incrementally decoding PNGs (i.e. decode part of
> an image, then decode further with more data).
>
> Bug: skia:5368
> BUG:34073812
>
> Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
> Reviewed-on: https://skia-review.googlesource.com/13900
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=msarett@google.com,scroggo@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2f82e9960dda7bf5c646774df84320dadb7b930e
Reviewed-on: https://skia-review.googlesource.com/13971
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This is the other half of https://skia-review.googlesource.com/c/7874/,
adding the cull-shrinking feature of SkBigPictures to SkMiniPictures.
Like SkBigPictures, shrink only when we're asked to build an R-tree.
(We don't actually build a tree for one rect, of course.)
We could do unconditionally, but SkPictureImageFilter uses the cull rect
as its crop. It's unclear to me what this image filter unit test I've
changed here was intending... had it had two draws we would have shrunk
its cull, but because it was hitting the 1-draw SkMiniPicture path it
kept the larger user-supplied cull.
As the test doesn't appear to have been written with cull shrinking in
mind, I've removed its SkRTreeFactory to keep that feature explicitly
disabled there.
BUG=skia:5974
Change-Id: I4118d2e85f2a69adef2e7a7fa9b9b8c17607a94f
Reviewed-on: https://skia-review.googlesource.com/12624
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I658a95576143d69656cd63aec44ff65d430d332f
Reviewed-on: https://skia-review.googlesource.com/13813
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Previously, SkPngCodec assumed that the stream only contained one
image, which ended at the end of the stream. It read the stream in
arbitrarily-sized chunks, and then passed that data to libpng for
processing.
If a stream contains more than one image, this may result in reading
beyond the end of the image, making future reads read the wrong data.
Now, SkPngCodec starts by reading 8 bytes at a time. After the
signature, 8 bytes is enough to know which chunk is next and how many
bytes are in the chunk.
When decoding the size, we stop when we reach IDAT, and when decoding
the image, we stop when we reach IEND.
This manual parsing is necessary to support APNG, which is planned in
the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
was a workaround for reading more than necessary at the beginning of
the image.
Add a test that simulates the issue, by decoding a special stream that
reports an error if the codec attempts to read beyond the end.
Temporarily disable the partial decoding tests for png. A larger change
will be necessary to get those working again, and no clients are
currently relying on incrementally decoding PNGs (i.e. decode part of
an image, then decode further with more data).
Bug: skia:5368
BUG:34073812
Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
Reviewed-on: https://skia-review.googlesource.com/13900
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
This refactors from_half() and to_half() a bit, totally
reimplementing the non-hardware cases to be more clearly correct.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Android-Clang-PixelC-CPU-TegraX1-arm64-Release-Android,Test-Android-Clang-Ci20-CPU-IngenicJZ4780-mipsel-Release-Android,Test-Android-Clang-Nexus10-CPU-Exynos5250-arm-Release-Android,Test-Mac-Clang-MacMini6.2-CPU-AVX-x86_64-Release,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug
Change-Id: I439463cf90935c5e8fe2369cbcf45e07f3af62c7
Reviewed-on: https://skia-review.googlesource.com/13921
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Have the callsites of SkOpTAllocator call SkArenaAlloc directly.
Bug: skia:
Change-Id: Ic54e92c3e9a0abed038aa3ae40e8a195895af99d
Reviewed-on: https://skia-review.googlesource.com/13870
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Herb Derby <herb@google.com>
I've tried a couple of ideas for approx_powf():
1) accumulate integer powers of x, then 4th roots, then 16th roots
2) continue 1) all the way to 256th roots
3) decompose into pow2 and log2, exploiting IEEE float layout
4) slightly tune constants used in 3)
5) accumulate integer powers of x, then 3+4) with different tuning
6) follow a source online, basically 5 with finesse
7) a new source quoting and improving on the method in 6).
7) seems perfect, enough that maybe we can explore improving its speed
at cost of precision. Might be nice to get rid of those divides. If we
allow a small tolerance (2-5) in our tests, we could use the very simple
fast forms from 3) (e.g. PS 5). I wish I had some images to look at!
Anything involving roots seems to be subverted by poor rsqrt precision.
This change of course affects the pipelines created by the tests for
exponential and full parametric gamma curves. What's less obvious is
that it also means SkJumper can now for the first time run the pipeline
created by the mixed gamma curves test. This means we now need to relax
our tolerance for the table-based channel, just like we did when
implementing table_{r,g,b,a}.
This took me an embarassingly long time to figure out. *face palm*
Change-Id: I451ee3c970a0a4a4e285f8aa8f6ef709a654d247
Reviewed-on: https://skia-review.googlesource.com/13656
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Change-Id: I7fab6d1c7240c17f2cc8436e8c6e7c8d2df940bb
Reviewed-on: https://skia-review.googlesource.com/13814
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Test for degenerate values after computing the ratio, instead of
attempting to catch all tricky cases upfront.
BUG=skia:6511
Change-Id: I8e3421675994dd68a1eff1af3f1456917dd1f9e1
Reviewed-on: https://skia-review.googlesource.com/13726
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Change-Id: Id41d3e03390185f72b682225aeb140df45c84a34
Reviewed-on: https://skia-review.googlesource.com/13763
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
- On both GL and Vulkan, we must draw if writing to an MSAA surface.
Otherwise we just write to the resolve target texture, which gets
overwritten on the next resolve.
- On Vulkan, we must draw if the target isn't a texture. (This check
was already present in onWritePixels).
- On Vulkan, when reading from an MSAA surface as a different config,
we don't need the readConfig to be renderable with MSAA - the temp
surface is always created non-MSAA.
- Added tests for these fixes, verified that they failed previously.
Bug: skia:
Change-Id: Ia2d5025d7a8f8de8630413453f83b58028dd41aa
Reviewed-on: https://skia-review.googlesource.com/13691
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
A pair of coincident lines can generate multiple intersection
points. Path ops is more stable when the intersection T value
is used to recompute the intersection point, but this has
the side-effect of making integral edges intersect at non-integral
values.
While it's worthwhile to fix this, for the moment it is less
disruptive to only worry about keeping intersection values
integral if the original intersection point is integral in
both axes.
Also, fix some debugging code that bit-rotted.
R=msarett@google.com
Change-Id: Iefd27b25d1d21c22b224c174bd59bc6c105033c4
Reviewed-on: https://skia-review.googlesource.com/13721
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
