aboutsummaryrefslogtreecommitdiffhomepage
path: root/third_party/libpng/pnglibconf.h
Commit message (Collapse)AuthorAge
* roll libpng to 1.6.33Gravatar Mike Klein2017-10-02
| | | | | | | | | | | | | Apparently 1.6.34 has been released too, but I can't find it in Git, and 1.6.33 is the one with that patch we're really interested in, right? Let's also just #include the prebuilt pnglibconf.h to make it clear that it's unchanged from the original? Change-Id: Ia415486f30c7aff1575f96add8edce855eef9207 Reviewed-on: https://skia-review.googlesource.com/54040 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* libpng: update to 1.6.32, pull using DEPSGravatar Mike Klein2017-09-19
| | | | | | | | | | | I'd have done this as two steps, but we didn't have a pure copy of libpng to start with. The patches we did have, though, have been upstreamed and are now unneeded. Change-Id: I884b9bc47afe5000f5a521f66a3bb95c0411b39a Reviewed-on: https://skia-review.googlesource.com/48620 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Prefix png functionsGravatar scroggo2016-06-06
| | | | | | | | | This way multiple copies of libpng can coexist. Update libpng's README.google GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2046603002 Review-Url: https://codereview.chromium.org/2046603002
* Update pnglibconf.hGravatar scroggo2016-06-06
| | | | | | | | | | It should have been updated when we updated the version. Update README.google to better reflect the difference from the original file. GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2042833002 Review-Url: https://codereview.chromium.org/2042833002
* Update libpng to 1.6.22betaGravatar msarett2016-02-19
| | | | | | | | | | 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
* Update the version of libpng used by Skia testsGravatar scroggo2016-02-19
| | | | | | | | | | | | | | | | | | | | The version of libpng we were using has some security vulnerabilities. Update to a newer version - 1.6.20 (http://sourceforge.net/p/libpng/code/ci/047737496a77eeb97f9991919dac08ca3c149711/). 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
* sketch hooking into PNG_FILTER_OPTIMIZATIONSGravatar mtklein2016-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix the build on Android devicesGravatar Matt Sarett2015-11-06
|
* Enable both static and dynamically linked libpngGravatar djsollen2015-04-03
| | | | | | | | | | | 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
* Revert of Enable both static and dynamically linked libpng (patchset #4 ↵Gravatar djsollen2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | 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
* Enable both static and dynamically linked libpngGravatar djsollen2015-04-01
| | | | | | | | 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
* Add SkCodec, including PNG implementation.Gravatar scroggo2015-03-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* remove libpng and zlib from third_party Gravatar epoger@google.com2011-06-16
| | | | | | | | http://codereview.appspot.com/4571077 git-svn-id: http://skia.googlecode.com/svn/trunk@1609 2bbb7eff-a529-9590-31e7-b0007b416f81
* add libpng source to repo and make Unix build use itGravatar epoger@google.com2011-06-15
http://codereview.appspot.com/4572067 git-svn-id: http://skia.googlecode.com/svn/trunk@1591 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-12 06:20:00 +0000