| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
created new file src/core/SkColorData.h for
internal consumption. Note that many of the
functions there are unused as well.
Bug: skia: 6898
R: reed@google.com
Change-Id: I25bfd5a9c21f53558c4ca65a77eb5d322d897c6d
Reviewed-on: https://skia-review.googlesource.com/46848
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Reed <reed@google.com>
|
|
|
|
|
|
|
| |
BUG=skia:4456
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1907593004
Review URL: https://codereview.chromium.org/1907593004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decode should not depend on the requested alpha type.
These were exposed by:
https://codereview.chromium.org/1641273003
This should cause the number of untriaged images in Gold
to go to zero.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1663303002
Review URL: https://codereview.chromium.org/1663303002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a client requests unpremul or premul from an opaque SkCodec,
support it. The opaque image can be treated as any of them, though
it will be less efficient to draw than if the client had used
opaque.
Change the filling code (i.e. for incomplete images) to base its color on
the source alpha type. Prior to adding the support to decode opaque to
any, it was fine to use either source or dest (which would have yielded
the same result). If the client requests non-opaque, we do not want this
to switch the fill value from black to transparent. This also allows
simplifying the signatures for getFillValue and onGetFillValue.
In CodexTest, expect the same result when decoding opaque to *premul,
and compare to the opaque version.
BUG=skia:4616
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1641273003
Review URL: https://codereview.chromium.org/1641273003
|
|
|
|
|
|
|
|
| |
TBR=reed
BUG=skia:3582
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1557403002
Review URL: https://codereview.chromium.org/1557403002
|
|
|
|
|
|
|
|
|
|
|
|
| |
We will implement this API using SkCodecs.
SkAndroidCodecs will be used to implement the
BitmapRegionDecoder Java API (and possibly
BitmapFactory).
BUG=skia:
Review URL: https://codereview.chromium.org/1406223002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now, that we are subsetting, fX0 is not necessarily less than
fSrcWidth (since fSrcWidth is really the subset width).
Ex: We may want a 10 pixel subset starting twenty pixels from the
left edge. In that case, fX0=20 and fSrcWidth=10.
Let's rename the width as fSubsetWidth to avoid confusion
and remove the check.
BUG=skia:
Review URL: https://codereview.chromium.org/1407603003
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL allows the SkScanlineDecoder to decode partial
scanlines.
This is a first step in efficiently implementing subsetting
in SkScaledCodec.
BUG=skia:4209
Review URL: https://codereview.chromium.org/1390213002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this CL, each SkCodec subclass that allows sampling does an
extra check in onStartScanlineDecode to determine whether the X dimension
is supported for sampling. Remove this check, and provide a way for
SkScaledCodec to directly access the SkSwizzler, and update it to do
sampling. This way, the SkCodec knows nothing of sampling, but we can
still save the extra step of sampling afterwards.
FIXME: SkBmpRLECodec still calls SkScaledCodec::DimensionsSupported. It
seems like it could directly support sampling, rather than dealing with
SkScaledCodec (partially).
Add a new base class for SkSwizzler. It allows updating the swizzler
after it was created, which is done by SkScaledCodec. Modify SkSwizzler's
constructor/factory function to stop taking any info about sampling,
assume the sample size is one, and move modifying that into a virtual
function overridden from the base class.
BUG=skia:4284
Review URL: https://codereview.chromium.org/1372973002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Redesigns SkScanlineDecoder.h to indicate the ordering
in which the scanlines are provided
Refactors SkSwizzler::Fill() to include the zeroInit check
and to actually be correct.
BUG=skia:3257
BUG=skia:4198
Review URL: https://codereview.chromium.org/1287423002
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316233002
Review URL: https://codereview.chromium.org/1316233002
|
|
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316123003
Review URL: https://codereview.chromium.org/1316123003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more swizzling functions for swizzling to 565. Much of this
code was revived from crrev.com/1055743003 (for BMP). Also added
swizzling functions for WBMP.
Consolidate the static function conversion_possible.
In SkCodec::getPixels, check that the alphatype corresponds to the
colorType. This prevents requesting 565 + non-opaque.
In SkIcoCodec, report that the image is unpremul (instead of
whatever the largest embedded codec thinks), but modify the
requested info to have the alpha type expected/required by the
embedded codec.
Add tests for decoding to 565.
BUG=skia:3257
BUG=skia:3683
Review URL: https://codereview.chromium.org/1277213002
|
|
|
|
|
|
|
|
|
|
|
| |
Per our discussion, we can make the swizzler simpler and more usable
for SkCodec and SkScanlineDecoder by only having a single version of
next() which takes a pointer to the srcRow and a pointer to the
dstRow.
BUG=skia:
Review URL: https://codereview.chromium.org/1256373002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may want to enable swizzles to 565
for images that are encoded in a format
similar to 565, however, we do not want
to take images that decode naturally to
kN32 and then convert them to 565.
***Enable swizzles to kIndex_8. For images
encoded in a color table format, we suggest
that they be decoded to kIndex_8. When we
decode, we only allow conversion to kIndex_8
if it matches the suggested color type (except
wbmp which seems good as is).
***Modify dm to test images that decode to
kIndex_8.
BUG=skia:3257
BUG=skia:3440
Review URL: https://codereview.chromium.org/1055743003
|
|
|
|
|
|
|
|
|
|
| |
We now support kN32 and kRGB_565 color types.
Additionally, we support premul, unpremul, and opaque alpha types.
Unpremul is currently untested as we cannot currently draw to unpremul.
BUG=skia:
Review URL: https://codereview.chromium.org/1013743003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:1 of https://codereview.chromium.org/1007373003/)"
This reverts commit d18475854ce232de71c5463e0654f459d4abfd43.
Revert "Revert "Implementation of image decoding for bmp files, in accordance with the new API.""
This reverts commit dfdec78a5d02e8690998741a9fe5b71a08ca3232.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1016443003
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the new API."
This reverts commit 3675874468de7228944ce21922e6ec863f5f2310.
BUG=skia:
NOTREECHECKS=true
NOTRY=true
TBR=
Review URL: https://codereview.chromium.org/1012873002
|
|
Currently decodes to opaque and unpremul.
Tested on local test suite.
BUG=skia:3257
Review URL: https://codereview.chromium.org/947283002
|