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>
Bug: skia:
Change-Id: Ibc6698b4db8aabeb14224d2c3ec8412f7ecfecb9
Reviewed-on: https://skia-review.googlesource.com/14146
Reviewed-by: Brian Osman <brianosman@google.com>
This is probably it until GrTexture.h can be hidden.
TBR=bsalomon@google.com
Change-Id: Ie743c937f72aa0dc9f5e84def572f655f0abe041
Reviewed-on: https://skia-review.googlesource.com/14143
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL splits the InstancedRendering class into an allocator and a per-opList op tracker. This was done because we need to allocate the InstancedRendering ops before we know the final destination opList. The InstancedRendering ops are now still all allocated from the same pool but the tracking and execution is done per opList.
Change-Id: Ieddabb6f85f8f187c5e7373f7f6cb155d69a9685
Reviewed-on: https://skia-review.googlesource.com/13860
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
As long as everything is laid out the same way they were originally, I don't
think there's any reason we can't just use %rip-relative addressing on x86-64.
Basically, we just need to keep all the sections together in order.
Somewhat subtly we cannot just use -D to disassemble all sections. -D will
double-disassemble[1] some bytes, which throws off our %rip-relative addressing
of constants. You can see this in PS1. So we whitelist sections instead.
[1], from man objdump:
This option also has a subtle effect on the disassembly of instructions in code
sections. When option -d is in effect objdump will assume that any symbols
present in a code section occur on the boundary between instructions and it will
refuse to disassemble across such a boundary. When option -D is in effect however
this assumption is supressed. This means that it is possible for the output of -d
and -D to differ if, for example, data is stored in code sections.
Change-Id: Idbcfe08e67113b3f7d75749931c640ff90aa0bf4
Reviewed-on: https://skia-review.googlesource.com/14029
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@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>
These are slow enough that they sometimes trigger GPU timeout.
Bug: skia:6534
Change-Id: Ie16a533e5ae132599d6514ae15a22d4fce4cb0fd
Reviewed-on: https://skia-review.googlesource.com/14064
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Fixes 4 gms in gbr-8888 config.
Bug: skia:6516
Change-Id: I9da839eb0211910989be35db0e13c0e1bbfa185d
Reviewed-on: https://skia-review.googlesource.com/13964
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Also adds an SkColorSpace to the BitmapShader
cache key (that should have been there already).
This fixes 3 gms in gbr-8888 config.
Bug: skia:
Change-Id: If47dfcdbd99b4caaeee4eddbe5ff1cd042ea9d02
Reviewed-on: https://skia-review.googlesource.com/13976
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
This (only?) affects ANGLE. Other ES platforms typically go through
EGLGLTestContext, which manually instantiates an EGLFenceSync.
In general, though, ES3 requires this API, so this is safe. Should give us
more accurate (and much less spammy) output from ES3 ANGLE performance
testing.
Bug: skia:
Change-Id: I10a608d21092aaffa4ab76e4b3d2f6e9c5cf09bb
Reviewed-on: https://skia-review.googlesource.com/14063
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Starting with the bug fix + test.
Broken off of:
https://skia-review.googlesource.com/c/13976
Bug: skia:
Change-Id: If6c28e2dfb0c5340c48e943d0313a9ea9515a6c3
Reviewed-on: https://skia-review.googlesource.com/14061
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Change-Id: I5de3c8daae80e437b3553ab6afcee7120a1bb775
Reviewed-on: https://skia-review.googlesource.com/14038
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I still plan to replace this more thoroughly with a different blitter,
but for now just implement it using callback.
This is the last stage not supported by SkJumper! Will follow up by
removing all of SkRasterPipeline_opts.h and anything that indicates
SkJumper might not work.
Change-Id: I96ba2bb0a26266f3b658e5f3153ec7d5bbd46799
Reviewed-on: https://skia-review.googlesource.com/14037
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
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>
Bug: skia:
Change-Id: I560eb00b4b19643346b038822869e5bc77ce1454
Reviewed-on: https://skia-review.googlesource.com/13652
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
NOTRY=true
Change-Id: I19b8e8d126df7580aed689af9155a34781baa8d5
Reviewed-on: https://skia-review.googlesource.com/14032
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
I don't suppose you know any existing test coverage of this?
I can't seem to trigger any...
Change-Id: I7244053e2fb665888c9443d2bc52c5a23725ec53
Reviewed-on: https://skia-review.googlesource.com/13970
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The new code path is triggered by SkImage::makeColorSpace()
when the image is picture backed.
Fixes 3 gms in gbr-8888 config.
Bug: skia:6516
Change-Id: I397903eb0f926834efd277f30265339518777920
Reviewed-on: https://skia-review.googlesource.com/14034
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Looks like the color-space images have this well tested (even without
lab_to_xyz) and the diffs look like rounding/FMA.
The old plan to keep loads and stores outside callback was:
1) awkward, with too many pointers and pointers to pointers to track
2) misguided... load and store stages march ahead by x,
working at ptr+0, ptr+8, ptr+16, etc. while callback
always wants to be working at the same spot in the buffer.
I spent a frustrating day in lldb to understood 2). :/
So now the stage always store4's its pixels to a buffer in the context
before the callback, and when the callback returns it load4's them back
from a pointer in the context, defaulting to that same buffer.
Instead of passing a void* into the callback, we pass the context
itself. This lets us subclass the context and add our own data...
C-compatible object-oriented programming.
Change-Id: I7a03439b3abd2efb000a6973631a9336452e9a43
Reviewed-on: https://skia-review.googlesource.com/13985
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
* Fix spot shadow placement for SkSpotShadowMaskFilter.
* Make sure we don't try to render an oval as a plain RRect
due to floating point error.
* Use fast path for uncached circles.
* Make sure ShadowMaskFilters can handle near-circles.
Change-Id: Ia9967a00a6e1c980a1c0a7ba8248f09fde61a3b7
Reviewed-on: https://skia-review.googlesource.com/13969
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Addresses an issue with ovals transformed by a matrix with a reflection.
Also adds a further check for circles to ensure that teeny tiny ovals
(sizes < SK_ScalarNearlyZero) aren't treated as circles.
Change-Id: Ie50e4a98365eba7c23e53e68886ebac981ed1def
Reviewed-on: https://skia-review.googlesource.com/13989
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
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>
Currently the Vulkan backend is set up to always treat the "resolve"
target as the main VkImage in a render target and the msaa is a side cart
image. This makes it difficult to just wrap an msaa image that we don't own.
However, unlike GL the equivalent FBO 0 will never be multisampled so there
isn't much use for the functionality. Once we find a need for it we can find
a way to refactor to make it work.
Bug: skia:
Change-Id: I121e9c72a70c2a6f1aaddba2dbae19d8bddc3998
Reviewed-on: https://skia-review.googlesource.com/13980
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Galaxy S6 was way quicker on average: 19 min vs 33 min
https://docs.google.com/spreadsheets/d/1tO1YA3RL36FBGgrfpV-cr1v9srFMowBtlwywSG0frYI/edit#gid=0
We'll only keep the Nexus 5 on for a few weeks, in case we decide to go back.
Bug: skia:
NOTRY=true
Change-Id: I36cc617d4ea274bfaf5b54e9c6d73715d40d65a8
Change-Id: I36cc617d4ea274bfaf5b54e9c6d73715d40d65a8
Reviewed-on: https://skia-review.googlesource.com/13982
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
This removes a long-standing source of confusion: SkImage_Generator was an
image that wrapped an SkImageGenerator (with an SkImageCacherator stuck in
the middle). We could choose to rename either one, but SkImageGenerator is
public, so take the easy road and rename the private image subclass. Given
the existence of SkImage::isLazyGenerated, this name seems appropriate.
Bug: skia:
Change-Id: I061ece94f48538efb1dc5548010f6ca7d438a69b
Reviewed-on: https://skia-review.googlesource.com/13979
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I'm guessing the crash is actually on the first 'fGpu' reference in createTextureProxy after the GPU context has been abandoned.
Bug: 712929
Change-Id: Ia6742da7073c2320e592b42fcf2d0e7c04eeefb9
Reviewed-on: https://skia-review.googlesource.com/13966
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit edec99b640.
Reason for revert: should be good to try again.
Original change's description:
> jumper, disable u16 table load stages
>
> Bug: b/37433905
>
> Change-Id: I829d76967f9da162388bad3f6bc2484d2a28043d
> Reviewed-on: https://skia-review.googlesource.com/13771
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=mtklein@chromium.org,msarett@google.com,reviews@skia.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I173bc284f894eae969bf670735e3bd723605df80
Reviewed-on: https://skia-review.googlesource.com/13967
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
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>
On all GPUs where we can perfectly round-trip, this mode does so.
This mode fails on Mali 400 and Tegra 3, but nothing works there.
Bug: skia:
Change-Id: Ifb045fc772a5b1c03b51b5cb2ae039fe792d17bb
Reviewed-on: https://skia-review.googlesource.com/13271
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@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>
Tweaks to make the parallels between from_half and to_half stand out.
We can logically do the `auto denorm = em < ...;` comparisons as either
U32 or I32. U32 would read more naturally, but we do I32 because some
instruction sets have direct signed comparison but must synthesize an
unsigned comparison.
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: Ic74fe5b3b850f5bb7fd00fd4435bc32b8628eecd
Reviewed-on: https://skia-review.googlesource.com/13963
Reviewed-by: Matt Sarett <msarett@google.com>
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>
We only need to verify that we've tested the PM conversion if we're about
to use GrConfigConversionEffect. For the else case, no such guarantee is
made, so the assert is wrong.
Bug: chromium:713462
Change-Id: I5ffcc0c5f7de4e9614e9ccd83140acc9ab4f7283
Reviewed-on: https://skia-review.googlesource.com/13962
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@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 change is needed since once we start getting support for varrying of extensions
and newer version support in general, we need a common vulkan header to compile off of.
Otherwise we will run into problems if clients have older headers that don't include
functions/symbols we are trying to use.
Additionally it has the benefit of not needing to add if SK_VULKAN around code in
include which wants to use vulkan symbols.
This is a reland of the reverted cl: https://skia-review.googlesource.com/13804
Bug: skia:
Change-Id: I9023e80e60d2f2ebbdc8e794ec46d6f5c5c7c917
Reviewed-on: https://skia-review.googlesource.com/13874
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Greg Daniel <egdaniel@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>
- Move to SkJumper_vectors.h
- Fold the -127 and +2.774485010.
- approx_powf(F,F) instead of approx_powf(F,float) for consistency.
- A little layout reformatting.
Change-Id: If9cb3d62a097cb6ecf89f157a1dde672c1516371
Reviewed-on: https://skia-review.googlesource.com/13865
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
