The idea here is that we determine the 0.5 crossover for each
row in the gamma table, then invert the mapping to determine
which point that maps to in the original range [-.65,
.65]. That gives us a change in the apparent width of the
glyph that closely corresponds to the change produced by the gamma fix.
BUG=skia:2933
Review URL: https://codereview.chromium.org/1042373002
CodecBench:
Add new class for timing using SkCodec.
DecodingBench:
Include creating a decoder inside the loop. This is to have a better
comparison against SkCodec. SkCodec's factory function does not
necessarily read the same amount as SkImageDecoder's, so in order to
have a meaningful comparison, read the entire stream from the
beginning. Also for comparison, create a new SkStream from the
SkData each time.
Add a debugging check to make sure we have an SkImageDecoder.
Add include guards.
nanobench.cpp:
Decode using SkCodec.
When decoding using SkImageDecoder, exclude benches where we decoded
to a different color type than requested. SkImageDecoder may decide to
decode to a different type, in which case the name is misleading.
TODOs:
Now that we ignore color types that do not match the desired
color type, we should add Index8. This also means calling the more
complex version of getPixels so CodecBench can support kIndex8.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044363002
This mirrors the behavior in onGetPixels, and allows the implementation
to share code for handling calls to rewindIfNeeded.
This also fixes a bug where getScanlineDecoder was calling
rewindIfNeeded and treating the result as a bool.
In SkPngCodec, factor out the code to call rewindIfNeeded, and call it
in both onGetPixels and onGetScanlineDecoder.
Update the test to include testing the scanline decoder. Rename "gen"
to "codec" now that it must be an SkCodec.
BUG=skia:3257
Depends on https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUE).
Review URL: https://codereview.chromium.org/1050893002
Reason for revert:
breaking the nexus_9 and ios builds.
Original issue's description:
> Enable both static and dynamically linked libpng
>
> All platforms except android are configured to use the statically linked copy of libpng. Android uses the system provided dynamic copy for SkImageDecoder and the static copy for SkCodec. The exception being android framework builds that currently use the dynamic copy everywhere.
>
> This CL also enables NEON optimizations for libpng.
>
> Committed: https://skia.googlesource.com/skia/+/2469c999518e7b0063d35e9e2eb074a0477c21acTBR=scroggo@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1050183002
All platforms except android are configured to use the statically linked copy of libpng. Android uses the system provided dynamic copy for SkImageDecoder and the static copy for SkCodec. The exception being android framework builds that currently use the dynamic copy everywhere.
This CL also enables NEON optimizations for libpng.
Review URL: https://codereview.chromium.org/1032253003
Separate out the code for reading the header, and use it to reinitialize
fPng_ptr and fInfo_ptr after a rewind.
Use common code to clean up fPng_ptr and fInfo_ptr, and set them to
NULL and treat them as NULL as appropriate.
Update the test to expect SkPngCodec to succeed.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1048423003
Reason for revert:
Looks like this change is causing layout test failures which is blocking Skia's DEPS roll into Chromium:
https://codereview.chromium.org/1050563002/https://codereview.chromium.org/1043133005/https://codereview.chromium.org/1048273002/
Reverting to see if this fixes the DEPS roll.
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057443003
Let's start with baby steps in case some bot can't handle this.
I have left many TODOs, most of which I know how to do if this
looks feasible and useful.
BUG=skia:
Review URL: https://codereview.chromium.org/1049223003
Motivation: Keep separate features separate. Also, future
linearization work will need to have several objNumMap
objects share a substituteMap. Also "catalog" has a
specific meaning in PDF. This catalog did not map to that
catalog.
- Modify SkPDFObject::emitObject and SkPDFObject::addResources
interface to requiore SkPDFObjNumMap and SkPDFSubstituteMap.
- SkPDFObjNumMap const in SkPDFObject::emitObject.
- Remove SkPDFCatalog.cpp/.h
- Modify SkDocument_PDF.cpp to use new functions
- Fold in SkPDFStream::populate
- Fold in SkPDFBitmap::emitDict
- Move SkPDFObjNumMap and SkPDFSubstituteMap to SkPDFTypes.h
- Note (via assert) that SkPDFArray & SkPDFDict don't need to
check substitutes.
- Remove extra space from SkPDFDict serialization.
- SkPDFBitmap SkPDFType0Font SkPDFGraphicState SkPDFStream
updated to new interface.
- PDFPrimitivesTest updated for new interface.
BUG=skia:3585
Review URL: https://codereview.chromium.org/1049753002
In software, SkDraw1Glyph::Proc SkDraw1Glyph::init initializes
fHalfSampleX, fHalfSampleY to SkGlyph::kSubpixelRound. In hardware,
however, these values were initialized to zero.
Fix, match software's implementation
BUG=471919
Review URL: https://codereview.chromium.org/1047803004
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Review URL: https://codereview.chromium.org/1034733002
Make webpages_playback support storing to local directories as an
alternative to Google Storage.
Rename argument --dest_gsbase to --data_store=<location>. Make this parameter
accept either gs:// url or directory for local file system storage.
Rename argument --upload_to_gs to --upload.
Implement file existence check, download and upload for the file
operation.
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/737123005
Some tools would like to be built with all resources embedded.
This change makes it possible to build a font manager which
uses font data embedded into the executable.
Review URL: https://codereview.chromium.org/1015723004
The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N. Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster). Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.
This also makes implementing new specializations easier and more encapsulated. We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h and SkNx_neon.h.
This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.
To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet. I will happily add them back if they seem useful.
You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc. Here's how you should feel:
- Sk4f, Sk4s, Sk2d: feel awesome
- Sk2f, Sk2s, Sk4d: feel pretty good
No public API changes.
TBR=reed@google.com
BUG=skia:3592
Review URL: https://codereview.chromium.org/1048593002
Move the .wpr files after recording, in the recording retry loop.
Previously they were moved in the skp capture retry loop.
Review URL: https://codereview.chromium.org/1033223005
Need to land SK_SUPPORT_LEGACY_SCALAR_MAPPOINTS in chrome to suppress Affine
version which causes slight differences (which will need to be rebaselined)
BUG=skia:
Review URL: https://codereview.chromium.org/1045493002
