SkImageGeneratorCG:
- Detect the origin and apply it to the output
- Deprecate NewFromEncodedCG and add MakeFromEncodedCG
SkCodecImageGenerator:
- Move code elsewhere for sharing
- Apply origin for incomplete decodes
SkPixmap.cpp/SkPixmapPriv.h:
- Now has the shared code for generators to apply origin
DMSrcSink.cpp:
- Call MakeFromEncodedCG
SkCGUtils.h:
- Add a version of SkCopyPixelsFromCGImage that takes an SkPixmap
Bug: skia:7138
Bug: skia:3834
Change-Id: Ic6dbc76360c6a84913b67373582f328d3946d637
Reviewed-on: https://skia-review.googlesource.com/63740
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This allows the via to work with GPU (where we don't render to N32).
Change-Id: I42e8457731a5ee51d14f7092eebd6efe72decd84
Reviewed-on: https://skia-review.googlesource.com/65822
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 5b9a037bf4.
Reason for revert:
I got confused in here somewhere and everything is drawing wrong.
Original change's description:
> gbr- has been brg- this whole time...
>
> Rewrite things to make that a little clearer.
>
> A red pixel ends up in channel 2, what would naively draw as blue
> without a rotation. A green pixel ends up in channel 0, which would
> naively draw as red without rotation. A blue pixel ends up in channel
> 1, which would naively draw as green without this rotation.
>
> So this transformation is:
>
> r -> b
> g -> r
> b -> g
>
> i.e. rgb_to_brg
>
> Change-Id: I12331ff2622194e34a44f421f656fbe4db5d3dca
> Reviewed-on: https://skia-review.googlesource.com/65521
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@chromium.org,brianosman@google.com
Change-Id: Ib29800b242bf736b20d61375d3c437c8f4ffdce0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/65781
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Rewrite things to make that a little clearer.
A red pixel ends up in channel 2, what would naively draw as blue
without a rotation. A green pixel ends up in channel 0, which would
naively draw as red without rotation. A blue pixel ends up in channel
1, which would naively draw as green without this rotation.
So this transformation is:
r -> b
g -> r
b -> g
i.e. rgb_to_brg
Change-Id: I12331ff2622194e34a44f421f656fbe4db5d3dca
Reviewed-on: https://skia-review.googlesource.com/65521
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Ic9e6cfe82dd22ac01be7a51724efa4c00399cfef
Reviewed-on: https://skia-review.googlesource.com/65320
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
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>
For configs that compare results of two drawing methods, it's helpful to
know how the two images differed. This takes both images, PNG encodes them
(at maximum compression settings), then base64 encodes them into data URIs
so they can be viewed directly from the logs.
These kinds of failures are typically very rare, and currently happen
infrequently due to flaky GMs - we don't want to be using this kind of
facility all the time.
Bug: skia:7011
Change-Id: Ib6c271cb8f6cd657cf6ca8ccfee97d0193b4e6ed
Reviewed-on: https://skia-review.googlesource.com/43240
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
We like a LIFO default thread pool in tools like DM for better
memory/time locality... the bots use less memory this way, and
generally run faster.
But most use cases want a FIFO queue, so that they can get going
on the next parts of early work while later work is still running.
This splits the implementation into one using SkTArray and pop_back
for LIFO, and a new one using std::deque and pop_front for FIFO.
Change-Id: Ief203b6869a00f1f8084019431a781d15fc63750
Reviewed-on: https://skia-review.googlesource.com/41849
Commit-Queue: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I35bc08ad72fb94d8e47fe342d314c4496b954226
Reviewed-on: https://skia-review.googlesource.com/40881
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Chrome would like to perform cpu-side preprocessing for gpu draws in parallel.
They do not want to go through a picture (since they have their own display list format).
The general idea is that we add a new SkDeferredDisplayListRecorder class to
perform all of Ganesh's cpu-side preprocessing ahead of time and in parallel.
The SkDDLRecorder operates like SkPictureRecorder. The user can get an SkCanvas
from the SkDDLRecorder and feed it draw operations. Once finished, the user
calls 'detach' to get an SkDeferredDisplayList. All the work up to and
including the 'detach' call can be done in parallel and will not touch
the GPU. To actually get pixels the client must call SkSurface::draw(SkDDL)
on an SkSurface that is "compatible" with the surface characterization
initially given to the SkDDLMaker.
The surface characterization contains the minimum amount of information Ganesh needs
to know about the ultimate destination in order to perform its cpu-side work
(i.e., caps, width, height, config).
Change-Id: I75faa483ab5a6b779c8de56ea56b9d90b990f43a
Reviewed-on: https://skia-review.googlesource.com/30140
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Re-land of: https://skia-review.googlesource.com/36560
All information needed by the thread is captured by the prepare
callback object, the lambda captures a pointer to that, and does the
mask render. Once it's done, it signals the semaphore (also owned by the
callback). The callback defers the semaphore wait even longer (into the
ASAP upload), so the odds of waiting for the thread are REALLY low.
Also did a bunch of cleanup along the way, and put in some trace markers
so we can monitor how well this is working.
Traces of a GM that includes GPU and SW path rendering (path-reverse):
Original:
https://screenshot.googleplex.com/f5BG3901tQg.png
Threaded, with wait in the callback (notice pre flush callback blocking):
https://screenshot.googleplex.com/htOSZFE2s04.png
Current version, with wait deferred to ASAP upload function:
https://screenshot.googleplex.com/GHjD0U3C34q.png
Bug: skia:
Change-Id: Idb92f385590749f41328a9aec65b2a93f4775079
Reviewed-on: https://skia-review.googlesource.com/40775
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This was created by looking at warnings produced by clang's
-Wzero-as-null-pointer-constant. This updates most issues in
Skia code. However, there are places where GL and Vulkan want
pointer values which are explicitly 0, external headers which
use NULL directly, and possibly more uses in un-compiled
sources (for other platforms).
Change-Id: Id22fbac04d5c53497a53d734f0896b4f06fe8345
Reviewed-on: https://skia-review.googlesource.com/39521
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This reverts commit 76323bc061.
Reason for revert: Breaking NUC bots in threaded gm comparison:
https://chromium-swarm.appspot.com/task?id=382e589753187f10&refresh=10
Original change's description:
> Threaded generation of software paths
>
> All information needed by the thread is captured by the prepare
> callback object, the lambda captures a pointer to that, and does the
> mask render. Once it's done, it signals the semaphore (also owned by the
> callback). The callback defers the semaphore wait even longer (into the
> ASAP upload), so the odds of waiting for the thread are REALLY low.
>
> Also did a bunch of cleanup along the way, and put in some trace markers
> so we can monitor how well this is working.
>
> Traces of a GM that includes GPU and SW path rendering (path-reverse):
>
> Original:
> https://screenshot.googleplex.com/f5BG3901tQg.png
> Threaded, with wait in the callback (notice pre flush callback blocking):
> https://screenshot.googleplex.com/htOSZFE2s04.png
> Current version, with wait deferred to ASAP upload function:
> https://screenshot.googleplex.com/GHjD0U3C34q.png
>
> Bug: skia:
> Change-Id: I3d5a230bbd68eb35e1f0574b308485c691435790
> Reviewed-on: https://skia-review.googlesource.com/36560
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,mtklein@google.com,bsalomon@google.com,robertphillips@google.com,brianosman@google.com
Change-Id: Icac0918a3771859f671b69ae07ae0fedd3ebb3db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/38560
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
All information needed by the thread is captured by the prepare
callback object, the lambda captures a pointer to that, and does the
mask render. Once it's done, it signals the semaphore (also owned by the
callback). The callback defers the semaphore wait even longer (into the
ASAP upload), so the odds of waiting for the thread are REALLY low.
Also did a bunch of cleanup along the way, and put in some trace markers
so we can monitor how well this is working.
Traces of a GM that includes GPU and SW path rendering (path-reverse):
Original:
https://screenshot.googleplex.com/f5BG3901tQg.png
Threaded, with wait in the callback (notice pre flush callback blocking):
https://screenshot.googleplex.com/htOSZFE2s04.png
Current version, with wait deferred to ASAP upload function:
https://screenshot.googleplex.com/GHjD0U3C34q.png
Bug: skia:
Change-Id: I3d5a230bbd68eb35e1f0574b308485c691435790
Reviewed-on: https://skia-review.googlesource.com/36560
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We were ignoring the path renderer flag when drawing GMs or SKPs.
Bug: skia:
Change-Id: Iee443fb70f1faec65e46925fa0e3cea3716d448d
Reviewed-on: https://skia-review.googlesource.com/36861
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
review.skia.org/34361 accidentally started attempting to decode images
with transparency to a 565 sink. BRD helpfully decodes to N32 instead,
rather than failing. We don't need to test this here, and it draws to a
565 sink, resulting in incorrect images in Gold.
Change-Id: I9585b2c0c4526e5f33667bd8f57003449e735372
Reviewed-on: https://skia-review.googlesource.com/35707
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Move common code into the base class, so subclasses need not call
conversion_possible.
Use SkEncodedInfo rather than SkImageInfo, and use the proper frame.
API Changes:
- SkAndroidCodec:
- Add getEncodedInfo(), for SkBitmapRegionCodec
- SkEncodedInfo:
- Add opaque() helper
- SkBitmapRegionDecoder:
- Remove unused conversionSupported
(Split off from skia-review.googlesource.com/c/25746)
Bug: skia:5601
Change-Id: If4a40d4b98a3dd0afde2b6058f92315a393a5baf
Reviewed-on: https://skia-review.googlesource.com/34361
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
rm gm that appears to have been there solely for pdf, but we don't use
it for that now.
Bug: skia:
Change-Id: I3cf88db923c2445b7c95dda14da679a594117643
Reviewed-on: https://skia-review.googlesource.com/31760
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Will need guards for android (at least)
Bug: skia:
Change-Id: I2bb8e656997984489ef1f2e41cd3d301c4e7b947
Reviewed-on: https://skia-review.googlesource.com/26040
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: Ia50661a8391da526d509adbe2d7203866c140b1c
Reviewed-on: https://skia-review.googlesource.com/25321
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
[√] convert all stages to use SkJumper_MemoryCtx / be 2d-compatible
[√] convert compile to 2d also, remove 1d run/compile
[√] convert all call sites
[√] no diffs
Change-Id: I3b806eb8fe0c3ec043359616409f7cd1211a1e43
Reviewed-on: https://skia-review.googlesource.com/24263
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Change-Id: I395e3387df44cf5370fef6ab73db73228225622f
Reviewed-on: https://skia-review.googlesource.com/23946
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 742a3e298f.
Reason for revert: Breaking Android roll:
frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:453:18: error: no member named 'fColorPtr' in 'SkAndroidCodec::AndroidOptions'
codecOptions.fColorPtr = colorPtr;
~~~~~~~~~~~~ ^
frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:454:18: error: no member named 'fColorCount' in 'SkAndroidCodec::AndroidOptions'
codecOptions.fColorCount = colorCount;
~~~~~~~~~~~~ ^
Original change's description:
> Remove support for decoding to kIndex_8
>
> Fix up callsites, and remove tests that no longer make sense.
>
> Bug: skia:6828
> Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295
> Reviewed-on: https://skia-review.googlesource.com/21664
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Commit-Queue: Leon Scroggins <scroggo@google.com>
TBR=djsollen@google.com,scroggo@google.com
Change-Id: I1bc669441f250690884e75a9a61427fdf75c6907
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:6828
Reviewed-on: https://skia-review.googlesource.com/22120
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Fix up callsites, and remove tests that no longer make sense.
Bug: skia:6828
Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295
Reviewed-on: https://skia-review.googlesource.com/21664
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Previously, SkGifCodec treated an error in the LZW data as incomplete,
since we can still draw the partially decoded image. But a client doing
incremental decodes needs to distinguish this from truly incomplete
data. In the case of an error, the client should not attempt to provide
more data and decode again.
Add kErrorInInput, and return it when SkGifCodec sees a fatal error.
Treat it the same as kIncompleteInput when it comes to filling and DM.
Bug: skia:6825
Change-Id: Ic6ce3a62c0b065ed34dcd8006309e43272a3db9f
Reviewed-on: https://skia-review.googlesource.com/21530
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Chris Blume <cblume@chromium.org>
We have removed support for drawing Index8, so stop testing it in DM.
Bug: skia: 6828
Change-Id: Ib2c4d3ebd371be704151a9f956c0ca2aaf2926a6
Reviewed-on: https://skia-review.googlesource.com/21525
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit 81c83a7db4.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Revert "Do not return Index8 from SkAndroidCodec::computeOutputColorType"
>
> This reverts commit b6f4767294.
>
> Reason for revert: This breaks CTS tests in Android. Doh.
>
> Original change's description:
> > Do not return Index8 from SkAndroidCodec::computeOutputColorType
> >
> > Given that this is the only known use of Index8 color type,
> > this is essentially an experimental delete.
> >
> > Bug: skia:6620
> > Change-Id: Ib363d237e0217f6e7f461a62e54d32892c428095
> > Reviewed-on: https://skia-review.googlesource.com/10586
> > Reviewed-by: Leon Scroggins <scroggo@google.com>
> > Commit-Queue: Matt Sarett <msarett@google.com>
>
> TBR=msarett@google.com,scroggo@google.com,reed@google.com
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:6620
>
> Change-Id: I2b44c695b8b95659520e9532901f636f56e01e2a
> Reviewed-on: https://skia-review.googlesource.com/19084
> Reviewed-by: Matt Sarett <msarett@google.com>
> Commit-Queue: Matt Sarett <msarett@google.com>
TBR=msarett@google.com,scroggo@google.com,reviews@skia.org,reed@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:6620
Change-Id: I7e4e3a5ec068102244ad3a0259aa6aded4f12f36
Reviewed-on: https://skia-review.googlesource.com/19802
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Verified that this fixes the wrongness of a few of the colorImage
diffs in Gold.
Bug: skia:6738
Change-Id: Icf0b7573ccb87268b480d7cc0a6cfe6fa8ae73f7
Reviewed-on: https://skia-review.googlesource.com/19271
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
This reverts commit b6f4767294.
Reason for revert: This breaks CTS tests in Android. Doh.
Original change's description:
> Do not return Index8 from SkAndroidCodec::computeOutputColorType
>
> Given that this is the only known use of Index8 color type,
> this is essentially an experimental delete.
>
> Bug: skia:6620
> Change-Id: Ib363d237e0217f6e7f461a62e54d32892c428095
> Reviewed-on: https://skia-review.googlesource.com/10586
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Commit-Queue: Matt Sarett <msarett@google.com>
TBR=msarett@google.com,scroggo@google.com,reed@google.com
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:6620
Change-Id: I2b44c695b8b95659520e9532901f636f56e01e2a
Reviewed-on: https://skia-review.googlesource.com/19084
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Given that this is the only known use of Index8 color type,
this is essentially an experimental delete.
Bug: skia:6620
Change-Id: Ib363d237e0217f6e7f461a62e54d32892c428095
Reviewed-on: https://skia-review.googlesource.com/10586
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
SkCodec sets fRequiredFrame to be the earliest possible frame that a
given frame can depend on. e.g.
- Frame A fills the screen, Keep
- Frame B does not cover A, Keep
- Frame C covers B but not A, and is opaque
Frame C can depend on either A or B. SkCodec already reports that C
depends on A. This CL allows a client of SkCodec to use either A or
B to create C.
Also expose the DisposalMethod. Since any frame between A and C can
be used to create C except for DisposePrevious frames, the client
needs to be able to know the disposal method so they do not try to
use such a frame to create C.
Further, the disposal method can be used to give the client a better
idea whether they will continue to need a frame. (e.g. if frame i is
DisposePrevious and depends on i-1, the client may not want to steal
i-1 to create i, since i+1 may also depend on i-1.)
TODO: Share code for decoding prior frames between GIF and WEBP
Change-Id: I91a5ae22ba3d8dfbe0bde833fa67ae3da0d81ed6
Reviewed-on: https://skia-review.googlesource.com/13722
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Chris Blume <cblume@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
y isn't used yet. This is just a warmup that updates the callers.
Change-Id: I78f4f44e2b82f72b3a39fa8a8bdadef1d1b8a99e
Reviewed-on: https://skia-review.googlesource.com/18381
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Tests were previously dependent on the fact that drawBitmap calls were
using the legacy sprite blitters. Now these tests are blocking the
change that fixes drawBitmap behavior.
https://skia-review.googlesource.com/c/17923/
Bug: skia:
Change-Id: Ia9e5244243f18680d7593b0fa9de942dbbeeeb1d
Reviewed-on: https://skia-review.googlesource.com/18027
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Bug: skia:6673
Change-Id: Ia2bae4f6a9039a007a10b6b45bcf2f0854bf6e5c
Reviewed-on: https://skia-review.googlesource.com/17794
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We special case N32, but need to also handle f16
Change-Id: I0d6061d55e55c5952c740255e4600366d8d77919
Reviewed-on: https://skia-review.googlesource.com/17786
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
TBR=reed@google.com
(No change to the public API, but changed a header file)
SkWebpCodec:
- Implement onGetFrameCount, onGetFrameInfo, and onGetRepetitionCount
- Respect the alpha reported by libwebp. Although the spec states that
it is only a hint, the libwebp encoder uses it properly. Respecting
allows us to draw opaque images faster and decode them to 565. This
also matches other SkCodecs (and Chromium).
- onGetPixels:
- Decode the frame requested, recursively decoding required frame if
necessary
- When blending with a prior frame, use SkRasterPipeline
SkCodec:
- Move check for negative index to getFrameInfo
- Reset the colorXform if one is not needed
SkCodecAnimation:
- Add new blend enum, for WebP's (and APNG's) non-blending option
SkFrameHolder:
- New base classes for frames and the owner of the frames, allowing
code sharing between SkWebpCodec and SkGifCodec (particularly for
determining whether a frame has alpha and what frame it depends on)
- When moving items from SkGIFFrameContext, use Skia conventions (i.e.
int instead of unsigned)
- Rename "delay time" to "duration", to match e.g. SkFrameInfo::
fDuration
SkGifImageReader:
- Move pieces to SkFrameHolder, and adapt to changes made in the
process
- Make setAlphaAndRequiredFrame (now on the base class SkFrameHolder)
more general to support webp, and add support for frames that do not
blend
- Change SkGIFFrameContext from a struct to a class, to match how we
use the distinction elsewhere (i.e. struct is a small object with
public fields)
- Rework hasTransparentPixel (now hasTransparency, since it returns true
in some cases where there is not a transparent pixel) to better fit
with the modified setAlphaAndRequiredFrame. Also be more consistent
when there is no transparent pixel but no color map.
- Simplify an if condition that was previously simplified in 2d61e717
but accidentally got reverted in a4db9be6
CodecAnimTest:
- Test new animated webp files
- Rearrange the test to more cleanly print alpha type mismatches for
the first frame
resources:
- webp-animated.webp
- animated webp from Chromium
- blendBG.webp
- new webp file using bits of webp-animated-semitransparent4.webp
from Chromium
- tests required frame and alpha when using the non-blending mode
- frames have the following properties:
- Frame 0: no alpha, fills screen
- Frame 1: alpha, fills screen
- Frame 2: no alpha, fills screen
- Frame 3: alpha, fills screen, blendBG
- Frame 4: no alpha, fills screen, blendBG
- Frame 5: alpha, blendBG
- Frame 6: covers 4, has alpha, blendBG
- also used to test decoding to 565 if the new frame data has alpha
but blends onto an opaque frame
DM.cpp:
- Test animated images to non-native 8888 and unpremul
DMSrcSink.cpp:
- Do not test non-native 8888 decodes to f16 dst
- Test unpremul decodes to f16
- Copy a frame of an animated image prior to drawing, since in unpremul
mode, the DM code will premultiply first.
Bug: skia: 3315
Change-Id: I4e55ae2ee5bc095b37a743bdcfac644be603b980
Reviewed-on: https://skia-review.googlesource.com/16707
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Summary of the new world...
--image
CodecSrc and ImageGenSrc tests run on:
(1) 8888 with kIgnore transfer fn behavior
(2) srgb with kRespect transfer fn behavior
(3) f16
AndroidCodecSrc and BRDCodecSrc tests run on:
(1) 8888, since SkAndroidCodec always uses kIgnore
(2) f16, since android uses f16
--colorImage
ColorCodecSrc tests run on:
(1) 8888 in kBaseline mode, so we can see what the raw pixels look like
(2) srgb in color correct modes
(3) f16 in color correct modes
Bug: skia:
Change-Id: I65d1a04051da6f94bf5e48f7bc610f482870dc75
Reviewed-on: https://skia-review.googlesource.com/17396
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This is fairly aggressive in that it will break any client
that is currently using SkImageGenerator with kIndex8.
I'm guessing that we don't have any clients doing that.
Bug: skia:6620
Change-Id: Ifd16f5232bb3a9f759c225315c57492d917ed9ca
Reviewed-on: https://skia-review.googlesource.com/16601
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
If/when we double check these settings we can either re-add these parameters or change the code manually.
The driving goal here is to shrink GrRenderTargetOpList.
Change-Id: I7819de18f97e8282e8754e3438130f797ebb3c37
Reviewed-on: https://skia-review.googlesource.com/14381
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
