Previously, REPORTER_ASSERT/ERRORF relied on a helper function named
`reporter_string` which papered over zero-argument and one-argument
messages (where one-argument messages are assumed to ignore printf
formatting rules entirely, and just forward the message as-is).
Replacing this helper with a direct call to `SkStringPrintf` allows
the compiler to check format arguments for correctness, but sacrifices
the one-argument special case. In practice the one-argument special
case was very rarely used, so it's not a significant sacrifice,
and this did uncover several real errors in assertion format strings
(including some cases where the wrong number of arguments was passed).
Change-Id: I4378c43b16fd8fdbf4c78d849a9f2f0a254f7abc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/506617
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:11968
In the simple constructor without an SkImageInfo, cropRect, etc, read
the orientation and swap the width and height if necessary. Although
SkAnimatedImage respects the orientation at decode time, initializing
with backwards width/height results in treating them as a scale.
Change-Id: I0500c3e9a99701c0ec2bba8994c356587a3c876c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406456
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
No known clients (CanvasKit, Android) want to ignore the exif
orientation in an animation.
A follow-on CL will deprecate SkAndroidCodec::ExifOrientation, leaving
it up to the client (e.g. SkAnimatedImage, hwui/ImageDecoder) to
handle the orientation. Add SkEncodedOriginSwapsWidthHeight to assist
clients to do so.
Update stoplight_animated_image GM. It previously showed using
SkAnimatedImage without respecting the orientation, which is no longer
supported. The new version replaces the left half of the image with the
right.
Remove assert that is no longer true. Originally, an SkAnimatedImage was
"simple" if it did not have a crop or postProcessor. This is no longer
true if has an exif orientation. Add a test that calls the simple
constructor and verifies it does not crash.
Change-Id: I421fd02700f220fb90458cd03c4431dee7daf399
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344762
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
A crop is invalid if it is empty/unsorted or does not intersect with
the image. Android (the only known client of the cropping API) will not
pass such a rectangle to the API, but this prevents other clients from
passing an invalid rectangle.
Change-Id: I09e007ecd378c358a1c604aff518035090f1e0a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333224
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Bug: skia:10914
SkAnimCodecPlayer:
- Properly handle orientation, whether the image is still or not
- Mark const methods as const
- Fix seek() so that if you seek to the duration of frame 0, it will
show frame 1
- Fix the SkImageInfo so if the first frame is opaque, but following
frames are not, those frames can still be decoded
resources:
- Rename "webp-animated.webp" to "stoplight.webp", which better
describes the animation
- Update test files accordingly
- Add "stoplight_h.webp", which is the same animation with an EXIF
that converts it to a horizontal stoplight
AnimCodecPlayer test:
- Test the new image files
- Verify SkAnimCodecPlayer::dimensions behaves as expected
- Remove extra debugging line
- Provide better error messages
AnimCodecPlayerExifGM:
- Add a new GM that shows all frames of the new animation with an EXIF
orientation
- Add a new GM that shows all frames of an animation with an opaque
first frame followed by frames with alpha
Change-Id: I43cf91c16d52aa1901eef8e13e1e644eea6058b3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/332753
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
sk_tool_utils doesn't really fit the naming convention
the rest of code under tools/ tends to use.
Change-Id: I45326a174101c6eb4b6149e9c742f658f2fd23b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202313
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Add a new constructor which merges the SkISize scaledSize with the
SkImageInfo. This allows passing an SkColorSpace to the decode.
Update the test to call the new API.
Bug: b/123301872
Change-Id: I9fd89198e97ac9b8e6dc9fcfe89ed38913a0fe69
Reviewed-on: https://skia-review.googlesource.com/c/189303
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Added as part of https://skia-review.googlesource.com/c/skia/+/132261/
As I understand it, this is no longer needed to prevent linear blending.
Change-Id: Ieddf1a86f2d5c6c874217549099a4168d2c44b47
Reviewed-on: https://skia-review.googlesource.com/c/189166
Commit-Queue: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Add a SK_LEGACY_SKCODEC_NONE_ENUM #define'able to ease transition.
Also rename another internal "kNone" enum in SkWebpCodec.cpp.
The "kNone" name is overloaded:
- include/core/SkImageGenerator.h defines its own kNone.
- include/encode/SkPngEncoder.h defines its own kNone.
- include/private/GrTypesPriv.h defines multiple kNone's.
Bug: skia:
Change-Id: I18c03a74f2f1b0237016e0eef53dcd4478b82609
Reviewed-on: https://skia-review.googlesource.com/146020
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This is the mechanism we'd want to add back if we add an sRGBA
SkColorType. This will break the DM "srgb" config hard.
Landing this first should help flush out GMs that are incidentally using
sRGB offscreens.
Updated tests/AnimatedImageTest.cpp to avoid linear sRGB 8888 surfaces.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Idb5035cf4d60fcd1dc24c303d43a406fc4a603fa
Reviewed-on: https://skia-review.googlesource.com/132261
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: 78866720
The client in Android calls newPictureSnapshot, which results in copying
the mutable SkBitmap into a newly allocated one in each frame. Avoid
this by calling SkMakeImageFromRasterBitmap with
kNever_SkCopyPixelsMode. Make SkAnimatedImage copy on write, by copying
before decoding if the bitmap's pixel ref is not unique.
Android's AnimatedImageDrawable's current architecture only decodes one
frame in advance, so it will never need to perform the copy on write.
This will save one bitmap allocation per GIF frame.
Add a test to verify that copy on write works as expected.
Change-Id: I87eb6e84089096cd2d618b91fb627fc58677e66a
Reviewed-on: https://skia-review.googlesource.com/129841
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Auto-Submit: Leon Scroggins <scroggo@google.com>
Bug: b/74195953
Do not use SkBlendMode::kSrc, which overwrites the pixels that were
already present. Instead, blend normally.
Change-Id: Ie6843c6278212fddddd0ba0ae292fdb5eaf2342e
Reviewed-on: https://skia-review.googlesource.com/112200
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: b/63908092
Rather than keeping track of the time and whether the animation is
running, leave that up to the client. Offer a single method to decode
the next frame, allowing the client to stay one frame ahead.
Change-Id: I546013e32e3a0874181b0dce1349bbec07aaadd4
Reviewed-on: https://skia-review.googlesource.com/101544
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: b/63908092
Android does not need to have its end listener attached if the
repetition count is infinite. Provide an accessor so it will know.
Change-Id: I481b048994a6e86ae88c913a5dcca3788b92bae2
Reviewed-on: https://skia-review.googlesource.com/99883
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: b/63908092
By default use the repetition count stored in the encoded data (if
any). Allow setting the repetition count manually, so that the
animation will stop after n+1 total cycles (unless -1 is used for
infinite).
If the animation is complete, make start reset it.
When the animation is not running, make update return max double (i.e.
no need to update any time soon).
Fix a bug where the first call to update returned -1.
Share write_bm with CodecAnimTest, for debugging.
Update Sample to check isRunning rather than keeping its own record
of whether the animation is running.
Change-Id: I883e4d7325f7a7b23a422fa9d756f9ea3018f0f8
Reviewed-on: https://skia-review.googlesource.com/97082
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
