Commit Graph

4 Commits

Author SHA1 Message Date
Mike Reed
8d29ab6309 Pass sampling to drawImage
Bug: skia:7650
Change-Id: I050841a401610b4a68b549602e27c0bac8e62067
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358196
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
2021-01-24 00:04:33 +00:00
Mike Reed
2ac6ce8e6e Simplify common case for recttorect
Change-Id: I70e295a677b8cac3d578e3cd57472c833af03877
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354336
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
2021-01-15 18:37:46 +00:00
Leon Scroggins III
e42716032b SkAnimatedImage: Always respect exif orientation
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>
2020-12-21 16:39:12 +00:00
Leon Scroggins
7d1153fc4c Handle EXIF orientation in SkAnimatedImage
Bug: skia:10914
Bug: b/163595585

In a WebP image, it is possible to combine animation with an EXIF
orientation. While SkAndroidCodec attempts to handle orientation itself
by decoding into temporary memory and then drawing through a matrix,
this doesn't work directly when compositing a P-frame into a prior
frame. SkAnimatedImage already uses an SkMatrix to handle cropping and
scaling, so update that matrix to include the orientation.

Make SkAnimatedImage a friend of SkAndroidCodec. This allows the former
to have the same ExifOrientationBehavior specified by the latter, and to
recreate the latter so it does not try to handle the orientation itself.

Clip SkAnimatedImage to its bounds. Android's AnimatedImageDrawable
performs its own clip, but this makes a crop rect work for other
clients.

Update getCurrentFrame to take cropping, scaling, and orientation into
account. This method is used by CanvasKit, which does not use cropping
or scaling, but will now properly orient an animation with an EXIF
orientation.

Add a GM that exercises the various combinations of ways SkAnimatedImage
can be used:
- via newPictureSnapshot (as in Android) versus getCurrentFrame
- scaling down to a dimension that can be output from the
  SkAndroidCodec, versus up, which SkAnimatedImage scales
- with a crop rect
- with a post processor

Change-Id: If1854e9aea23fc4afddf75d39132b38e3fbc6071
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333223
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
2020-11-12 19:47:59 +00:00