Commit Graph

10 Commits

Author SHA1 Message Date
msarett
740668d907 Update libpng to 1.6.22beta
Intel SSE filter optimizations have been upstreamed.  Let's test on
the upstream version (which we can use in Android).

BUG=skia:4573
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1710083007

Review URL: https://codereview.chromium.org/1710083007
2016-02-19 11:14:43 -08:00
scroggo
77b798ce8e Update the version of libpng used by Skia tests
The version of libpng we were using has some security vulnerabilities.
Update to a newer version - 1.6.20 (047737496a/).

Update pnglibconf.h. The new version is a copy of the newer version of
the file, with our /* custom settings */ tacked onto the end. (The
custom settings are unchanged from the last version.)

Update the LICENSE. The new version is a copy of the LICENSE that
libpng now includes as a separate file.

Update the README file to reflect the change in source of the LICENSE
file.

BUG=skia:4573
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1453373003

Review URL: https://codereview.chromium.org/1453373003
2016-02-19 06:33:07 -08:00
mtklein
372d65cc6e sketch hooking into PNG_FILTER_OPTIMIZATIONS
Local timing says this 4-byte Paeth function takes about 0.3x the time the serial libpng code does, dropping from ~10 cycles per byte to ~2.9.

bpp=4 is mainly an easy demo.  This approach can work for any bpp up to 16, 1 pixel at a time, at roughly the same cost per pixel.  Doing more than 1 pixel at a time is a tricky math problem I have yet to attempt to solve.

Everything here can be trivially downgraded to MMX, supporting bpp up to 8.  It seems to be a little slower (~3.5 cycles per byte), but it would make the code compatible with every x86 that can still power on.

I've tried four approaches:
  - this way;
  - doing things naively in 16-bit;
  - a 16-bit version that requires division by 3 (i.e. mulhi_epu16(..., 0x5580) );
  - a mostly 8-bit version of the same.

They're all fine, but this one is consistently the fastest I've measured.
I'd be happy to settle on the naive 16-bit version too, which would have a very clear implementation that's only minorly slower than this version.  The other two are way more complicated, and would require us to draw some serious ASCII diagrams to explain.

I have learned that the .skp serialization tests (serialize-8888) have a nice side effect of testing the correctness of these filters!

(Since writing the description above, I've bumped things up to {Paeth,Sub,Avg} x { 3 bpp, 4 bpp }.)

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1573943002

Review URL: https://codereview.chromium.org/1573943002
2016-01-27 13:01:41 -08:00
Matt Sarett
1aaaba5216 Fix the build on Android devices 2015-11-06 15:19:24 -05:00
djsollen
b2a6fe7976 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.

Review URL: https://codereview.chromium.org/1058823002
2015-04-03 12:35:27 -07:00
djsollen
1865900525 Revert of Enable both static and dynamically linked libpng (patchset #4 id:60001 of https://codereview.chromium.org/1032253003/)
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/+/2469c999518e7b0063d35e9e2eb074a0477c21ac

TBR=scroggo@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1050183002
2015-04-01 11:20:12 -07:00
djsollen
2469c99951 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.

Review URL: https://codereview.chromium.org/1032253003
2015-04-01 10:33:55 -07:00
scroggo
f24f2247c2 Add SkCodec, including PNG implementation.
DM:
Add a flag to use SkCodec instead of SkImageDecoder.

SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator

SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB

SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.

Requires a gclient sync to pull down libpng.

BUG=skia:3257

Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49
(and then reverted)

Review URL: https://codereview.chromium.org/930283002
2015-03-03 08:59:20 -08:00
epoger@google.com
b1b721a7b6 remove libpng and zlib from third_party
http://codereview.appspot.com/4571077



git-svn-id: http://skia.googlecode.com/svn/trunk@1609 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-06-16 12:27:14 +00:00
epoger@google.com
38a9134dbc add libpng source to repo and make Unix build use it
http://codereview.appspot.com/4572067



git-svn-id: http://skia.googlecode.com/svn/trunk@1591 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-06-15 13:45:10 +00:00