The file is expected to contain a list of strings. If the hash for
any result is in this file, don't write an image for it.
BUG=skia:3521
Review URL: https://codereview.chromium.org/1059363002
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/1058823002
SkCodec::NewFromStream claims to delete the passed in SkStream on
failure. This allows the caller to pass an SkStream to the function
and not worry about deleting it depending on the return value.
Most of our SkCodecs did not honor this contract though. Update them
to delete the stream on failure. Further, update SkCodec::NewFromStream
to delete the stream if it did not match any subclass, and delete the
SkCodec if we decided to return NULL because it was too big.
Add a test which tests streams which represent the beginnings of
supported format types but do not contain enough data to create an
SkCodec. The interesting part of the test is when we run it on ASAN,
which will report that we leaked something without the other changes.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1058873006
The colorfilter is applied to a single (paint's) color, so the bench does not
measure the filter at all, but simply the blit of a color.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1055383002
It's looking like the previous CL did not fix the Daisy bot GMs,
even though that's still the only bit of code I can find that was
ignoring color order. Puzzled. Reverting arm_version=7 for now.
BUG=skia:1843
Review URL: https://codereview.chromium.org/1051423002
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
I don't see any color-order handling logic in the 32-bit code.
BUG=skia:1843
CQ_EXCLUDE_TRYBOTS=client.skia.compile:Build-Win-MSVC-x86-Debug-Trybot,Build-Win-MSVC-x86_64-Debug-Trybot
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1051683003
This font contains two glyphs, one for 'a' and one for 'A'. The em size
is 128, and the 'a' fits in this. The big 'A', however, is ~3000 in
in each direction.
Review URL: https://codereview.chromium.org/1016153002
Each of these conversion functions now only asserts is output is valid.
For SkPMColor -> SkPMFloat, we assert isValid().
For SkPMFloat -> SkPMColor, we SkPMColorAssert.
#floats
BUG=skia:
BUG=skia:3592
Review URL: https://codereview.chromium.org/1055093002
- remove unused alex
- streamline Link's config
- remove misleading Daisy config:
1) armv7=1 does nothing. We meant to type arm_version=7 here.
2) arm_neon=1 does nothing unless arm_version == 7.
3) arm_thumb=0 is the default when arm_version <= 7.
4) skia_arch_width=32 is the default when skia_arch_type=arm.
I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and
arm_thumb=1, which I'm going to separately make the default for
arm_version=7), but there are known color-order bugs with our
NEON procs that would make Daisy start pushing bad images to
Gold. Going to take baby steps here...
BUG=skia:1843
Committed: https://skia.googlesource.com/skia/+/3c2809bc612f4a265770914f860d214c9665dc4a
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-CrOS_Daisy-Trybot
Review URL: https://codereview.chromium.org/1051253002
Reason for revert:
arm_thumb not defined
Original issue's description:
> tidy up chromeos_setup.sh
>
> - remove unused alex
> - streamline Link's config
> - remove misleading Daisy config:
> 1) armv7=1 does nothing. We meant to type arm_version=7 here.
> 2) arm_neon=1 does nothing unless arm_version == 7.
> 3) arm_thumb=0 is the default when arm_version <= 7.
> 4) skia_arch_width=32 is the default when skia_arch_type=arm.
>
> I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and
> arm_thumb=1, which I'm going to separately make the default for
> arm_version=7), but there are known color-order bugs with our
> NEON procs that would make Daisy start pushing bad images to
> Gold. Going to take baby steps here...
>
> BUG=skia:1843
>
> Committed: https://skia.googlesource.com/skia/+/3c2809bc612f4a265770914f860d214c9665dc4aTBR=borenet@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:1843
Review URL: https://codereview.chromium.org/1059443002
- remove unused alex
- streamline Link's config
- remove misleading Daisy config:
1) armv7=1 does nothing. We meant to type arm_version=7 here.
2) arm_neon=1 does nothing unless arm_version == 7.
3) arm_thumb=0 is the default when arm_version <= 7.
4) skia_arch_width=32 is the default when skia_arch_type=arm.
I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and
arm_thumb=1, which I'm going to separately make the default for
arm_version=7), but there are known color-order bugs with our
NEON procs that would make Daisy start pushing bad images to
Gold. Going to take baby steps here...
BUG=skia:1843
Review URL: https://codereview.chromium.org/1051253002
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, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) 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.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
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/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c
Review URL: https://codereview.chromium.org/1034733002
Add two drawPicture bracketing ops (BeginDrawPicture, EndDrawPicture) to
replace the current DrawPicture op, and flatten picture contents.
Review URL: https://codereview.chromium.org/1048383002
Reason for revert:
Spoke to Stephen about this. Reverting because failing debug builds:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54
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, SkMatrixConvolutionImageFilter,
> SkMatrixImageFilter) 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.
>
> For the SkMatrixConvolutionImageFilter, it seems the
> GLSL clamp() function occasionally returns values outside
> the clamped range, resulting in access of garbage
> texels even in GL_NEAREST. The fix here is to clamp to a
> rect inset by half a texel. There was also a bug in
> the unpremultiply step when fConvolveAlpha is false.
>
> For SkMatrixImageFilter, the fix was to make the generic
> draw path be more careful about when to use texture domain.
> If the bitmap already has a texture, use texture domain
> if the srcRect is smaller than the entire texture (not
> the entire bitmap).
>
> 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/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
>
> Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460cTBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057693002
