- explicitly reject already-texture-backed and picture-backed
Needed to add a virtual to image_base and generator to distinguish
generators that can (or cannot) natively "generate" on the gpu (e.g. pictures)
Bug: 646089
Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f
Change-Id: I3aea22f89b31009ecbb3bd50d88512e6532f0a0f
Reviewed-on: https://skia-review.googlesource.com/15765
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Lets clients know if an image is drawable to a particular GrContext
(or to CPU). Checks for abandoned GrContexts beneath GPU backed
images, as well as context mis-match.
Bug: skia:
Change-Id: Ibe88c7ce8091f965c14f6023a3597be4b70c3f99
Reviewed-on: https://skia-review.googlesource.com/15801
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
SkImageCacherator still exists, but only as an interface implemented
(solely) by SkImage_Lazy. The only external clients are
GrImageTextureMaker and SkImage_Gpu::getDeferredTextureImageData.
This is probably an improvement, but doesn't go as far as I'd hoped.
Bug: skia:
Change-Id: I6812badfabb6924b025621b21af00cbde9c16cac
Reviewed-on: https://skia-review.googlesource.com/14371
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
TBR=reed@roogle.com
Bug: skia:5485
Change-Id: Ia4ed45ffc39f2ba9a80d4a1001208079142ae985
Reviewed-on: https://skia-review.googlesource.com/14323
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
All variants of (on)?[rR]efEncoded(Data)? no longer need a GrContext
parameter.
Bug: skia:5485 skia:4971
Change-Id: If4f5e785718d5522eb3df8588318ccb8a02a5749
Reviewed-on: https://skia-review.googlesource.com/14269
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This fixes SkColorSpaceXformCanvas gms that expect
non-linear premuls from the codec.
BUG=skia:
Change-Id: I5dc236d0cd760c23605a26e9c33ddb18955f9231
Reviewed-on: https://skia-review.googlesource.com/10164
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
It does not seem irrational for generateTexture to always receive a valid GrContext. lockAsBitmap can do as it pleases.
This is split out of: https://skia-review.googlesource.com/c/8823/ (Remove GrFragmentProcessor-derived class' GrTexture-based ctors)
Change-Id: I8aebc813a8a3a7d694b7369c2c9810e2164fe16e
Reviewed-on: https://skia-review.googlesource.com/9191
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
BUG=skia:
Change-Id: I4bc11042dd1dbf1eabd40af206027bc65acc3186
Reviewed-on: https://skia-review.googlesource.com/8444
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This gives a picture image a preferred "native" color space, which
facilitates caching and other things.
BUG=skia:
Change-Id: I95988c14d17f96d7d870b3d1c3b723c36e2c170d
Reviewed-on: https://skia-review.googlesource.com/6158
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
generateBitmap was used in one test, so it's easily converted to
tryGenerateBitmap. Then, all calls to tryGenerateBitmap supplied
an image info, so we don't need it to be optional.
BUG=skia:
Change-Id: I19e8f9da7e442a2d37af68b029b5ec85228766f7
Reviewed-on: https://skia-review.googlesource.com/6149
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This adds support for playing back a picture image in a different
color space. This is currently limited to just the original space
(sRGB) or legacy mode. I think the best next step is to make them
fully flexible (playing back in the destination surface's space),
but that's going to involve changes to caching logic. I'd like to
keep that separate.
BUG=skia:
Change-Id: I15e6d44e977328b06a4da008ff7b2ed88d851a0b
Reviewed-on: https://skia-review.googlesource.com/5777
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
We were always already supplying this, makes it simpler
BUG=skia:
Change-Id: I36ac35205df5ab2a0fb7ec26e83ddb1547154816
Reviewed-on: https://skia-review.googlesource.com/5778
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Remove some unused variants of bitmap generation and a helper that
serves no purpose.
BUG=skia:
TBR=reed@google.com
Change-Id: I16022e7f0242c4511eebdc06d890f6bfdf81d1f9
Reviewed-on: https://skia-review.googlesource.com/5229
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Introduce an SkImageGenerator API to support the implementation of
externally-managed image decode and scale caches.
BUG=skia:5806
R=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4720
Change-Id: Ibfe37af5471f78f28f88f9d5e80938882be1a344
Reviewed-on: https://skia-review.googlesource.com/4720
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Enable reusing uniqueID when instantiating SkImageGenerator subclasses enables
using uniqueID in client code to cache generated bitmaps with no need to keep
the reference to SkImageGenerator.
This is a bug fix for out of memory cause in chromium and 100% CPU usage
described in issue 165750#13:
- cache uses SkImage::uniqueID() to cache decoded bitmaps.
- every animation loop creates new SkImage instances.
- after decoding, bitmap copies are added to cache, filling it up with
duplicates of previous loops frames.
BUG=165750
Blink patch that depends on this:
https://codereview.chromium.org/1925533003/
"High CPU and increased memory usage fix for high-res (GIF, WEBP...) animations."
Review-Url: https://codereview.chromium.org/1928403002
Prime motivator:
- we always call refEncoded on the generator when trying to upload
- we call it *before* we ask for raster or YUV
- for blink, this call can be very slow, as they have to cons-up their SkData the first time (and grab a mutex to do it)
- this parameter will indicate to them that we're only interested in gpu formats, which they will know if they have.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1556333004
Review URL: https://codereview.chromium.org/1556333004
This CL removes the uses of SkNEW that have resprouted since commit
385fe4d, and removes the macros entirely now that Android and Chromium
have been cleaned up to no longer depend on them.
A bunch of files implicitly depend on #include <new> from SkPostConfig.h
still though, so keep that for now. To be fixed in a followup CL.
[mtklein mucking around]
Only public API removed.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1360653004
Remove some bogus tests on the cache, as they are not thread-reliable. Running w/ discardable these are racy.
BUG=532981
Review URL: https://codereview.chromium.org/1351453004
To do this, create SkImageCacherator, which wraps a generator and provides an
interface to get a cached answer for either the raster or texture output of
the generator.
BUG=skia:
Review URL: https://codereview.chromium.org/1291803002
Follow up to the split between SkImageGenerator and SkCodec. Now that
SkCodec does not inherit from SkImageGenerator, SkImageGenerator no
longer needs Options or Result, which were added for SkCodec. Remove
them, but keep them behind a flag, since Chromium has its own
subclasses of SkImageGenerator which assume the old signature for
onGetPixels.
Review URL: https://codereview.chromium.org/1226023003
SK_SUPPORT_LEGACY_GET_PIXELS_ENUM just set a \#define to convert
onGetPixelsEnum
to
onGetPixels
Now that Chrome has been updated to override onGetPixels, there is no
need for the define.
BUG=skia:3257
Review URL: https://codereview.chromium.org/933853004
