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>
Match based on the whole test name.
No-Try: true
Change-Id: I03c180195f5854f30e521e2772dcb7e44f1cc3b8
Reviewed-on: https://skia-review.googlesource.com/46000
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 6d13575108.
Now with guards for "errors" like this:
external/skia/src/jumper/SkJumper_stages_8bit.cpp:240:50: error:
'memcpy' called with size bigger than buffer
case 12: memcpy(&v, src, 12*sizeof(T)); break;
This code is unreachable and generally removed by Clang's optimizer
anyway... as far as I can tell the code generation diff is arbitrary.
Change-Id: I6216567caaa6166f71258bd25343a09e93892a10
Reviewed-on: https://skia-review.googlesource.com/39961
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 08133583d5.
Reason for revert: Blocking Android Autoroller on compile error.
Original change's description:
> 8-bit jumper on armv8
>
> The GM diffs are all minor and what you'd expect.
>
> I did a quick performance sanity check, which also looks fine.
>
> $ out/ok bench rp filter:search=Modulate
> [blendmode_rect_Modulate] 30.2ms @0 32ms @95 32ms @100
> [blendmode_mask_Modulate] 12.6ms @0 12.6ms @95 14.5ms @100
> ~~~>
> [blendmode_rect_Modulate] 11.2ms @0 11.7ms @95 12.4ms @100
> [blendmode_mask_Modulate] 10.5ms @0 23.6ms @95 23.9ms @100
>
> This isn't even really the fastest we can make 8-bit go on ARMv8;
> it's actually much more natural to work de-interlaced there. Lots
> of room to follow up.
>
> Change-Id: I86b1099f6742bcb0b8b4fa153e85eaba9567cbf7
> Reviewed-on: https://skia-review.googlesource.com/39740
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,herb@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I71425d8b7fbb66be5cb50025871dd81358111da4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/39980
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
The GM diffs are all minor and what you'd expect.
I did a quick performance sanity check, which also looks fine.
$ out/ok bench rp filter:search=Modulate
[blendmode_rect_Modulate] 30.2ms @0 32ms @95 32ms @100
[blendmode_mask_Modulate] 12.6ms @0 12.6ms @95 14.5ms @100
~~~>
[blendmode_rect_Modulate] 11.2ms @0 11.7ms @95 12.4ms @100
[blendmode_mask_Modulate] 10.5ms @0 23.6ms @95 23.9ms @100
This isn't even really the fastest we can make 8-bit go on ARMv8;
it's actually much more natural to work de-interlaced there. Lots
of room to follow up.
Change-Id: I86b1099f6742bcb0b8b4fa153e85eaba9567cbf7
Reviewed-on: https://skia-review.googlesource.com/39740
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The only interesting difference here is that I've just skipped
cd_Documents() on Google3 iOS builds rather than adding a new target to
BUILD. We don't run the binary so it's kind of moot what directory it'd
run in.
Change-Id: I1994e0283d24bcc505fa9b2b7b58307eafa5be92
Reviewed-on: https://skia-review.googlesource.com/34742
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Broken by https://skia-review.googlesource.com/32862. It seems that
"tiles_rt" and "pic" configs were passing at one point, but have since
bit-rotted after being renamed to "tiles_rt-8888" and "pic-8888" and
thus ignored by dm.
No-Try: true
Change-Id: I00a5e5a0cc2090566809a61fa310c8ddaafdea43
Reviewed-on: https://skia-review.googlesource.com/33581
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Like _lowp.cpp, it's only meant to be compiled offline.
Change-Id: I0d4f7c1fd8fa880ffd084c1e332f6a33def6e26f
Reviewed-on: https://skia-review.googlesource.com/30262
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We will then rebase the tests in Google3 before completely removing
SK_NO_ANALYTIC_AA.
Bug: skia:
Change-Id: I47ec0cde78374bd53f7cdf7c0f2f6607ca6c18c2
Reviewed-on: https://skia-review.googlesource.com/27801
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit dbce07d803.
Reason for revert: need rebaseline in Google3
Original change's description:
> Remove the temporary flag SK_NO_ANALYTIC_AA
>
> It seems that this temp flag lives for too long...
>
> Bug: skia:
> Change-Id: I48b49af8b7f372abac88a8cd5440def3791e635a
> Reviewed-on: https://skia-review.googlesource.com/27662
> Reviewed-by: Cary Clark <caryclark@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
TBR=caryclark@google.com,fmalita@chromium.org,liyuqian@google.com,reed@google.com
Change-Id: I35a91923f16f4e1f530fae20599240cde73438b6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/27722
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
It seems that this temp flag lives for too long...
Bug: skia:
Change-Id: I48b49af8b7f372abac88a8cd5440def3791e635a
Reviewed-on: https://skia-review.googlesource.com/27662
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Yuqian Li <liyuqian@google.com>
No-Try: true
Change-Id: I738c6f79d9ad3af09010e64cee28129e503672a4
Reviewed-on: https://skia-review.googlesource.com/22071
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
msarett@ realized that if all of the encoders were disabled, then it
is equivalent to SkImageEncoder.cpp.
Change-Id: Ib3d5d7d061e1a60d7081689430107fb250903d5c
Reviewed-on: https://skia-review.googlesource.com/20440
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
The current roll is failing due to double linking:
multiple definition of 'SkEncodeImage(SkWStream*, SkPixmap const&, SkEncodedImageFormat, int)'
src/images/SkImageEncoder.pic.o: previous definition here
Change-Id: I64ada3591b4c4c0cb8deada0dc796d9a0376b6a7
Reviewed-on: https://skia-review.googlesource.com/18855
Reviewed-by: Matt Sarett <msarett@google.com>