Adds SkDrawPosTextHCommand ::fromJSON and ::toJSON.
Both SkDrawPosTextCommand and SkDrawPosTextHCommand's
::toJSON write the correct number of positions, preventing reading
uninitialized memory.
The microhttpd build is now done in the build tree as opposed to in a
temporary directory.
The microhttpd build script uses os.path.join so that absolute paths
do not confuse the build. This allows compatibility with the cmake
gyp generator as CMake likes to pass absolute paths.
The microhttpd gyp target is now marked as 'none' since it is not
a 'static_library' target (which directs gyp to compile sources into
a static library). The dependencies to the action are updated to the
minimum required for sane re-building.
The everything gyp target now depends on the skiaserve gyp target.
This means that when using skia_build_server=1, building 'most' will
build skiaserve, but when skia_build_server is not defined the
skiaserve target will still be available if specified manually.
The old json.gyp is removed as it currently does not build anything.
All of the files currently referenced by it as sources no longer exist.
Review URL: https://codereview.chromium.org/1775203002
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
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
Update FreeType to a newer version. Because this caused issues in
finding the correct ftoptions.h and ftmodule.h [1], be sure to state
the ones we want explicitly.
This also add gzip.c which is needed for WOFF support [2].
[1] FreeType "Simplify header file hierarchy."
fae382076409db198dfbff36ac4cbb97b05b30a1
[2] FreeType "[gzip] New function `FT_Gzip_Uncompress'."
dc240524ff31891a442225430b28e9620c1fa89f
Review URL: https://codereview.chromium.org/833103004
Reason for revert:
This will make the google3 roll awkward. Reverting.
Original issue's description:
> Depend on ETC1 via DEPS instead of a direct third_party checkin.
>
> Yes, this does mean we'll check out ~40M of code for 2 files...
>
> I think these trybots are moot... they gclient sync before patching.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/ca01d179347b5e848ded97c8228b79ffc6b5e7bfTBR=robertphillips@google.com,djsollen@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1290913008
Yes, this does mean we'll check out ~40M of code for 2 files...
I think these trybots are moot... they gclient sync before patching.
BUG=skia:
Review URL: https://codereview.chromium.org/1296253003
libwebp has a fix for [1]. Update to the commit that contains the fix.
Update libwebp.gypi, corresponding to libwebp's latest makefile.
Turn back on DM testing for scaled webp, now that it should no longer
use uninitialized memory.
Fix a warning in config.h
[1] https://code.google.com/p/webp/issues/detail?id=254
BUG=skia:4038
Review URL: https://codereview.chromium.org/1280073002
It turns out that gyp (kind of) has support for cross
compiling with a different host and target. We simply
need to specify CC_host and CC_target instead of CC.
Making this change allows us to compile yasm on a Linux
host for Android.
We run into problems on Mac because
the linker on a Mac host requires different command line
arguments than the linker on the Android target. In
looking through the code for gyp itself and speaking to
Ben, it doesn't appear to me that gyp supports passing
different arguments to host and target linkers.
I would imagine that we would have similar problems on
Windows.
Below is a link to a CL that would fix this issue in gyp.
It looks like it has been dropped for a long time.
Thanks to Ben for this link!
https://chromiumcodereview.appspot.com/10795044/
Also I'm adding a link to the build instructions for Chrome
(thanks again Ben). It looks like they only support
building for Android from Linux.
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
My next steps are:
1) Getting in touch with Torne or someone else with gyp to
see if people are aware of this issue or interested in
fixing it.
2) Deciding if skia should care about this issue.
3) Deciding if skia should work around this issue.
It'd be really great to hear your thoughts on (2) and (3).
My first thought is that we shouldn't care because, as
long as we always compile the production copy of skia for
Android on Linux, we will get the fast code. Is this
a valid conclusion? Is there a way to write Android apps
on Mac that accidentally use the slower code?
If we do care, there are workarounds:
For Mac, we can check in a yasm binary - it's a little
smaller than the one I am deleting in this CL :-/
For Windows, we *might* be able to use the yasm.exe binary
already in externals (we get this from DEPS because this is
how chromium uses yasm on Windows).
Are there other platforms that we care about?
Let me know what you think!
BUG=skia:4028
DOCS_PREVIEW= https://skia.org/?cl=1239333002
Review URL: https://codereview.chromium.org/1239333002
Mangle external function names to avoid conflict with libjpeg
Take advantage of direct color conversion (RGBA, BGRA, 565)
Prepare to use jpeg_skip_scanlines (when it is upstreamed)
BUG=skia:
Review URL: https://codereview.chromium.org/1180983002
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
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
