| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
This led to removing a lot of transfer function behavior code. There is
more that could be done, and we need to add in decoding to dst color
space, but this CL is almost entirely mechanical.
Change-Id: I91b2169f95aadcfaacdd2b9821bb1a01ce53f9a6
Reviewed-on: https://skia-review.googlesource.com/140349
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does not actually add any additional functionality to the generators.
Once this lands I will enable the generators one at a time to more easily
monitor the effects of each one.
Bug: skia:
Change-Id: I382a1acfaebcbf9ad44c9873b87cdbbe02a13602
Reviewed-on: https://skia-review.googlesource.com/57083
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
|
|
|
|
|
|
|
|
|
|
| |
Needs google3 to be updated before this can land.
Bug: skia:6828
Change-Id: I2c16be13c6937ffa48768cc24f9f980171c824d6
Reviewed-on: https://skia-review.googlesource.com/23940
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
|
|
|
|
|
|
|
|
|
| |
Bug: skia:6828
Change-Id: Ia942a36abb18213184f8d436555a658270d97d47
Reviewed-on: https://skia-review.googlesource.com/22721
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make SkImage_Lazy::onMakeColorSpace return a new SkImage_Lazy
with the color space of SkImage_Lazy::fInfo changed.
Update the call to SkImageGenerator::getPixels to specify
image info with this new color space.
Update the call to SkImageGenerator::generateTexture to specify
this new color space. Update SkPictureImageGenerator to respect
the color space argument. Add a SkTransferFunctionBehavior
argument to SkImageGenerator::generateTexture to indicate if
color conversion is to be doing using an xform canvas.
Update Generator_GrYUVProvider::refAsTextureProxy to include a
color conversion step to respect this new color space.
TBR=reed@google.com
Bug:739559
Change-Id: I156a858884659e9dfae739a653bab2ef89274959
Reviewed-on: https://skia-review.googlesource.com/21605
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Christopher Cameron <ccameron@chromium.org>
Reviewed-by: Christopher Cameron <ccameron@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
| |
Bug: skia:6620
Change-Id: I7ecdb5b162d8d468d91d4c8dbe276fabe349dc15
Reviewed-on: https://skia-review.googlesource.com/17215
Reviewed-by: Matt Sarett <msarett@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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
No "real" API changes.
TBR=reed@google.com
Bug: skia:
Change-Id: I08c29f76806388394938f204f2a50b2fd6ea8942
Reviewed-on: https://skia-review.googlesource.com/16662
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Bug: skia:
Change-Id: Ib63f96b83d696743bbe4335c998acd4d2ea8acdb
Reviewed-on: https://skia-review.googlesource.com/11787
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Reed <reed@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: I0c01fbf935be5d933aa2ef67a0fb2edba4941fa7
Reviewed-on: https://skia-review.googlesource.com/8835
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@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>
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
Change-Id: I9e042cd9343e0f29032f84ee17b4b316214ec693
Reviewed-on: https://skia-review.googlesource.com/8403
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
Change-Id: Ia1f975d8ca088a552258fd70d3333683a88bbb5f
Reviewed-on: https://skia-review.googlesource.com/6234
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@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>
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
Change-Id: I51b7778db8b596b2633b6be9488af984cee2af70
Reviewed-on: https://skia-review.googlesource.com/5713
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4492
Change-Id: I753ad01b03e891221965252e3befe280d09cdb9f
Reviewed-on: https://skia-review.googlesource.com/4492
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should match the recently designed API in SkCodec.
https://codereview.chromium.org/1549473003/
This requires changes in Chromium as well.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1716523002
Committed: https://skia.googlesource.com/skia/+/095d31c8a0eeb5d491febf064bc3c8a44e22b94f
Review URL: https://codereview.chromium.org/1716523002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/1716523002/ )
Reason for revert:
Blimp failures with manual roll in Chrome.
Original issue's description:
> Update Skia's YUV API
>
> We should match the recently designed API in SkCodec.
> https://codereview.chromium.org/1549473003/
>
> This requires changes in Chromium as well.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1716523002
>
> Committed: https://skia.googlesource.com/skia/+/095d31c8a0eeb5d491febf064bc3c8a44e22b94f
TBR=scroggo@google.com,reed@google.com,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1775493002
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should match the recently designed API in SkCodec.
https://codereview.chromium.org/1549473003/
This requires changes in Chromium as well.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1716523002
Review URL: https://codereview.chromium.org/1716523002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpu-specific formats
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1396323007
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1432503003
Review URL: https://codereview.chromium.org/1432503003
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1403313003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1404433002
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
just move block of code to expose it
BUG=skia:4328
TBR=
Review URL: https://codereview.chromium.org/1334033004
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316233002
Review URL: https://codereview.chromium.org/1316233002
|
|
|
|
|
|
|
|
| |
... to support subsets in SkImage!
BUG=skia:
Review URL: https://codereview.chromium.org/1301633002
|
|
|
|
|
|
|
|
|
|
|
|
| |
this, added uniqueID() to the generator, and made it be in the same namespace is bitmaps, pixelrefs, images.
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
|
|
|
|
|
|
| |
Now that Chrome no longer depends on it, remove dead code.
Review URL: https://codereview.chromium.org/1263013002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1223413002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1229933003
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1201233002
|
|
|
|
|
|
|
|
|
| |
need this to land in chrome first https://codereview.chromium.org/1125573002
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1123473004
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
need deps roll to see if this works... since skia can no longer build/test in this legacy mode.
Review URL: https://codereview.chromium.org/1026923002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1017293002
|
|
|
|
|
|
|
| |
This recreates SkImageDecoder's feature to skip writing zeroes for
SkCodec.
Review URL: https://codereview.chromium.org/980903002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the old signature of onGetPixels (return bool) to return an
enum (Result). Remove onGetPixelsEnum.
Add a define for onGetPixelsEnum to onGetPixels. This is for staging
in Chromium, where some implementations override onGetPixelsEnum.
Add the define in skia_for_chromium_defines. Remove
SK_SUPPORT_LEGACY_IMAGE_GENERATOR_RETURN, which is no longer needed by
Chromium.
BUG=skia:3257
Review URL: https://codereview.chromium.org/939113002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Needed for the DEPS roll.
TBR=jvanverth@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/921293002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new enum describes the nature of the failure. This is in
preparation for writing a replacement for SkImageDecoder, which will
use this interface.
Update the comments for getPixels() to specify what it means to pass
an SkImageInfo with a different size.
Make SkImageGenerator Noncopyable.
Leave onGetYUV8Planes alone, since we have separate discussions
regarding modifying that API.
Make callers of SkImageDecoder consistently handle kPartialSuccess.
Previously, some callers considered it a failure, and others considered
it a success.
BUG=skia:3257
Review URL: https://codereview.chromium.org/919693002
|