ffd8f62236..08fd250e1a
This picks up a number of fixes and an implementation of
FT_Get_Var_Design_Coordinates.
Change-Id: Idac2b3b5d2b0684fa2c13f4f2484c09f39a4eced
Reviewed-on: https://skia-review.googlesource.com/6815
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
A little JIT proof of concept for SkRasterPipeline, using xbyak, which is a header-only assembler. It's x86-only, but supports x86 very thoroughly, and it's very user friendly (at least as far as assembler libraries go...).
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Ie17e562b0f3fff5914041badfb2c1fe4f86efab8
Reviewed-on: https://skia-review.googlesource.com/5730
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Heather Miller <hcm@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
If a frame does not have a valid transparent index and it covers the
prior frame, it does not really depend on that frame. Instead, it
depends on the frame that the prior frame depends on.
Determine this once we have parsed the local color map (if any), so a
transparent index out of range of the color map is not considered
valid.
Share code that determines whether a frame has a transparent pixel.
Add a test that we compute the dependencies correctly. randPixelsAnim.gif
has 13 frames. After the first, the frames cover all combinations of
- Whether the prior frame was keep, restoreBG or restoreToPrevious
- Whether the new frame covers the prior frame
- Whether the new frame has a transparent pixel
(It only does so when using a global color table. It may make sense to
expand the test to also cover using local color tables.)
The test caught a bug where we incorrectly reused an existing
SkColorTable for a different frame. Fix that bug by keeping track of
the transparent index associated with the current SkColorTable.
Change-Id: I3cf6be7f612990fa7a00d9e74d116d31bd227526
Reviewed-on: https://skia-review.googlesource.com/6402
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
std::vector needs to be able to assign objects contained inside it. With
const member variables, this isn't possible. Remove the consts so
SkGIFLZWBlock can be assigned.
BUG=skia:6072
Change-Id: I990dc80fb1c49fbd584712c6d0c1154c2da36e85
Reviewed-on: https://skia-review.googlesource.com/6362
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
If the input SkStream has a length and position, do not copy and store
LZW blocks or ColorMaps. Instead, mark the position and size, and read
from the stream when necessary.
This will save memory in Chromium's use case, which has already
buffered all of its data.
In the case where we *do* need to copy, store it on the SkStreamBuffer.
This allows SkGifImageReader to have simpler code.
Add tests.
Change-Id: Ic65fa766328ae2e5974b2084bc2099e19aced731
Reviewed-on: https://skia-review.googlesource.com/6157
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit ada12ab055.
Reason for revert: Google3 needs it:
https://test.corp.google.com/ui#id=OCL:142184832:BASE:142184975:1481839118985:32fde8ef
Original change's description:
> Remove all KTX support
>
> It is untested and unused.
>
> Change-Id: I010ff4ad942738f362d42a99af4edbbb1cb0cd71
> Reviewed-on: https://skia-review.googlesource.com/6142
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
>
TBR=mtklein@chromium.org,mtklein@google.com,robertphillips@google.com,scroggo@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I1ea2f9487eb2212efbfcc514122792b70c9e8737
Reviewed-on: https://skia-review.googlesource.com/6181
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
It is untested and unused.
Change-Id: I010ff4ad942738f362d42a99af4edbbb1cb0cd71
Reviewed-on: https://skia-review.googlesource.com/6142
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
If there is enough data in the stream to read the reported canvas size,
but not enough to read the first image's header, we do not know the
true canvas size, since we may expand it to fit the first frame. In
that case, return nullptr from NewFromStream.
Add a test.
SkGifCodec.cpp:
Correct a comment - parse returns false if there is a fatal error.
parse() returning true does not guarantee that the size was found.
Instead of checking the width and height, check to see whether the
first frame exists and has its header defined. If not, we do not yet
know the true canvas size. Assert that the canvas size is non-zero,
which is a fatal error from parse.
SkGifImageReader.cpp:
Move the code to set the header defined before the SkGIFSizeQuery exit
condition. This allows SkGifCodec to check the first frame's header to
determine whether the size is known.
GifTest.cpp:
Add a test which truncates the file just before the image header (and
after the global header). Prior to the other changes, this would create
an SkCodec. For an image that needs its canvas size expanded, the
SkCodec would have an incorrect size.
CodecPartialTest.cpp:
randPixels.gif now needs more than half of its data to create an
SkCodec, so set a minimum for test_partial.
Change-Id: I40482f524128b2f1fe59b8f27dd64c7cbe793079
Reviewed-on: https://skia-review.googlesource.com/5701
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
SkGIFFrameContext::decode() and SkGIFLZWContext::prepareToDecode() do
not need (or use) the global color map, so stop passing it as a
parameter. The parameter was used prior to
https://skia-review.googlesource.com/c/4379/ (different issue!), but we
overlooked removing it then.
Change-Id: I0f477e9db11f7650938d6b868baef69e3b37d86b
Reviewed-on: https://skia-review.googlesource.com/5609
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
BUG=skia:
Change-Id: I876e802db370a7812cd53e42cb4927702e6c1fb6
Reviewed-on: https://skia-review.googlesource.com/5418
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Also, no more SkImageEncoder class.
SK_SUPPORT_LEGACY_IMAGE_ENCODER_CLASS now only guards some
old API shims.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5006
Change-Id: I3797f584f3e8e12ade10d31e8733163453725f40
Reviewed-on: https://skia-review.googlesource.com/5006
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This should fix Build-Mac-Clang-arm64-Debug-GN_iOS_NoBuildbot.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4755
Change-Id: Ie49ce5642fb2d373102c9309074e13ee3035a569
Reviewed-on: https://skia-review.googlesource.com/4755
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
These are so easy we might as well...
I did a quick check of relevant-looking defines:
- GYP defined WITH_SIMD, but it looks like that's already defined (by jconfig.h?);
- GYP defined RGBX_FILLER_0XFF, but that affects only x86/x86-64;
- GYP defined STRICT_MEMORY_ACCESS, which does nothing;
- GYP defined MOTION_JPEG_SUPPORTED, which does nothing (and we'd probably not care anyway).
BUG=skia:5875
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4745
Change-Id: Ib1f28d354630be472c4d9648d5ade74a452a9e24
Reviewed-on: https://skia-review.googlesource.com/4745
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
When we opt into Lua, this builds SampleLua into SampleApp, and the lua_app and lua_pictures tools.
I've tested this builds with and without skia_use_system_lua on my Mac laptop and Linux desktop.
I've made lua_pictures.cpp's flags static to avoid conflicts with flags in SkCommonFlags.cpp.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4699
DOCS_PREVIEW= https://skia.org/?cl=4699
Change-Id: I8176fd51d8a38746e7d730cfcce66da42b9a015a
Reviewed-on: https://skia-review.googlesource.com/4699
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I was profiling and remembered GN hasn't turned on much CPU-specific code. I looked at zlib, then libpng, then libjpeg-turbo:
- zlib was easy but not useful. No routine we use in decoding changes significantly.
- libpng was easy and useful, and we were already using NEON filters on ARM.
- libjpeg-turbo requires yasm and is annoying.
BUG=skia:5875
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4531
Change-Id: Ie072a457da41ee6538eebacb5eb5dbe5a6eb585e
Reviewed-on: https://skia-review.googlesource.com/4531
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
This stems from a behavior difference between Skia and Chrome.
In Skia, we want to write transparent pixels as often as possible.
(It's faster than checking if we should skip each pixel.)
In Chrome, they avoid writing transparent pixels unless
absolutely necessary.
We were cautious about changing behavior when this first landed,
but this is easier to think about in a smaller change (right now).
(1) We can always write transparent pixels when we are writing
an independent frame.
(2) There is no need for the progressiveDisplay() check. We
only ever use progressive display methods on the first
frame - and the first frame is always independent.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4379
Change-Id: I82048a08e2003aac216f483c7db8df997b687149
Reviewed-on: https://skia-review.googlesource.com/4379
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
This was always intended to be a temporary dependency to use for
testing. It has served its purpose.
Also, this has already been dropped (accidentally, I think) by
the new GN build.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4220
Change-Id: Ic72ee08bbfaf86ed86a4122fd38be2921eb1327e
Reviewed-on: https://skia-review.googlesource.com/4220
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This extends the pattern in freetype2 to expat, icu, libjpeg-turbo, libpng, libwebp, and zlib, and gives all these an arg to control which to use.
Homebrew doesn't have dng_sdk, piex, or sftnly, or I'd have done the same for them too.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4260
DOCS_PREVIEW= https://skia.org/?cl=4260
Change-Id: I82e780502bf2217336e791787f172a6fc8f55460
Reviewed-on: https://skia-review.googlesource.com/4260
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Hal Canary <halcanary@google.com>
Add a new accessor to retrieve the repetition count.
Remove constants (and corresponding copyright) in SkCodecAnimation.
These may make sense for the calling code, but are not needed here.
kRepetitionCountInfinite corresponds to Blink's kAnimationLoopInfinite.
Move cLoopCountNotSeen to private. It is used to determine whether we
still need to parse. Add a new enum to the parse query - only parse
enough to determine the repetition count.
Unlike Chromium, SkGifCodec does not account for deleting the reader
(which SkGifCodec does not do) or failed decodes.
Add a test.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447863002
Review-Url: https://codereview.chromium.org/2447863002
Add BUILD.gn files for dng_sdk and piex and updated BUILD.gn to
build SkRawCodec.
We stopped testing raw images when we switched to GN, so this will
bring back our testing.
Leave SkRawCodec disabled on Windows, where we've had problems in the
past.
Originally landed in issue 4603. Reverted due to build errors.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2463433002
Review-Url: https://codereview.chromium.org/2463433002
When checking to see whether a GIF has transparency to determine its
alpha type, treat an empty color table as having alpha, since we
will draw it as a transparent image.
(This is a separate bug from skbug.com/5883, but the image I used to
verify that bug was drawn to 565 as black. The fix is to not support
565 in that case, by changing its recommended alpha type.)
BUG=skia:5883
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2461813002
Review-Url: https://codereview.chromium.org/2461813002
Add BUILD.gn files for dng_sdk and piex and updated BUILD.gn to
build SkRawCodec.
We stopped testing raw images when we switched to GN, so this will
bring back our testing.
Leave SkRawCodec disabled on Windows, where we've had problems in the
past.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4063
Change-Id: I956949506200b766a2f7efb18e0486f3a2f93a1c
Reviewed-on: https://skia-review.googlesource.com/4063
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
SkMovie is not used in any of our tests or by Chromium. It is also not
supported by GN. It is being moved into Android, its only client, so we
can delete it here.
giflib is only used by SkMovie, so stop pulling/building it.
TBR=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3945
Change-Id: I28a8155fd59e139bb21ec2295cc22fdced034284
Review-Url: https://codereview.chromium.org/2449213004
565 cannot take the !writeTransparentPixels path, so disable it for
cases where we might have to take that path.
This only affects frames beyond the first. If the first frame has
a transparent pixel, it will be marked as non-opaque, so we cannot
decode to 565 anyway.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2441833002
Review-Url: https://codereview.chromium.org/2441833002
Add an interface to decode frames beyond the first in SkCodec, and
add an implementation for SkGifCodec.
Add getFrameData to SkCodec. This method reads ahead in the stream
to return a vector containing meta data about each frame in the image.
This is not required in order to decode frames beyond the first, but
it allows a client to learn extra information:
- how long the frame should be displayed
- whether a frame should be blended with a prior frame, allowing the
client to provide the prior frame to speed up decoding
Add a new fields to SkCodec::Options:
- fFrameIndex
- fHasPriorFrame
The API is designed so that SkCodec never caches frames. If a
client wants a frame beyond the first, they specify the frame in
Options.fFrameIndex. If the client does not have the
frame's required frame (the frame that this frame must be blended on
top of) cached, they pass false for
Options.fHasPriorFrame. Unless the frame is
independent, the codec will then recursively decode all frames
necessary to decode fFrameIndex. If the client has the required frame
cached, they can put it in the dst they pass to the codec, and the
codec will only draw fFrameIndex onto it.
Replace SkGifCodec's scanline decoding support with progressive
decoding, and update the tests accordingly.
Implement new APIs in SkGifCodec. Instead of using gif_lib, use
GIFImageReader, imported from Chromium (along with its copyright
headers) with the following changes:
- SkGifCodec is now the client
- Replace blink types
- Combine GIFColorMap::buildTable and ::getTable into a method that
creates and returns an SkColorTable
- Input comes from an SkStream, instead of a SegmentReader. Add
SkStreamBuffer, which buffers the (potentially partial) stream in
order to decode progressively.
(FIXME: This requires copying data that previously was read directly
from the SegmentReader. Does this hurt performance? If so, can we
fix it?)
- Remove UMA code
- Instead of reporting screen width and height to the client, allow the
client to query for it
- Fail earlier if the first frame AND screen have size of zero
- Compute required previous frame when adding a new one
- Move GIFParseQuery from GIFImageDecoder to GIFImageReader
- Allow parsing up to a specific frame (to skip parsing the rest of the
stream if a client only wants the first frame)
- Compute whether the first frame has alpha and supports index 8, to
create the SkImageInfo. This happens before reporting that the size
has been decoded.
Add GIFImageDecoder::haveDecodedRow to SkGifCodec, imported from
Chromium (along with its copyright header), with the following changes:
- Add support for sampling
- Use the swizzler
- Keep track of the rows decoded
- Do *not* keep track of whether we've seen alpha
Remove SkCodec::kOutOfOrder_SkScanlineOrder, which was only used by GIF
scanline decoding.
Call onRewind even if there is no stream (SkGifCodec needs to clear its
decoded state so it will decode from the beginning).
Add a method to SkSwizzler to access the offset into the dst, taking
subsetting into account.
Add a GM that animates a GIF.
Add tests for the new APIs.
*** Behavior changes:
* Previously, we reported that an image with a subset frame and no transparent
index was opaque and used the background index (if present) to fill the
background. This is necessary in order to support index 8, but it does not
match viewers/browsers I have seen. Examples:
- Chromium and Gimp render the background transparent
- Firefox, Safari, Linux Image Viewer, Safari Preview clip to the frame (for
a single frame image)
This CL matches Chromium's behavior and renders the background transparent.
This allows us to have consistent behavior across products and simplifies
the code (relative to what we would have to do to continue the old behavior
on Android). It also means that we will no longer support index 8 for some
GIFs.
* Stop checking for GIFSTAMP - all GIFs should be either 89a or 87a.
This matches Chromium. I suspect that bugs would have been reported if valid
GIFs started with "GIFVER" instead of "GIF89a" or "GIF87a" (but did not decode
in Chromium).
*** Future work not included in this CL:
* Move some checks out of haveDecodedRow, since they are the same for the
entire frame e.g.
- intersecting the frameRect with the full image size
- whether there is a color table
* Change when we write transparent pixels
- In some cases, Chromium deemed this unnecessary, but I suspect it is slower
than the fallback case. There will continue to be cases where we should
*not* write them, but for e.g. the first pass where we have already
cleared to transparent (which we may also be able to skip) writing the
transparent pixels will not make anything incorrect.
* Report color type and alpha type per frame
- Depending on alpha values, disposal methods, frame rects, etc, subsequent
frames may have different properties than the first.
* Skip copies of the encoded data
- We copy the encoded data in case the stream is one that cannot be rewound,
so we can parse and then decode (possibly not immediately). For some input
streams, this is unnecessary.
- I was concerned this cause a performance regression, but on average the
new code is faster than the old for the images I tested [1].
- It may cause a performance regression for Chromium, though, where we can
always move back in the stream, so this should be addressed.
Design doc:
https://docs.google.com/a/google.com/document/d/12Qhf9T92MWfdWujQwCIjhCO3sw6pTJB5pJBwDM1T7Kc/
[1] https://docs.google.com/a/google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=2045293002
Review-Url: https://codereview.chromium.org/2045293002
- Support ObjC / ObjC++
- Build SDL on Mac.
- Build viewer on Mac.
Patched from Jim's CL.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3760
Change-Id: I12663f2ed2969e22f51aefed560fbc22b2524167
Reviewed-on: https://skia-review.googlesource.com/3760
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-ANGLE-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3537
Change-Id: I5f2c7efeed77775b25d623de98894858a5458d50
Reviewed-on: https://skia-review.googlesource.com/3537
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Angle does not yet link, but it does compile.
I chickened out and wrote cp.py to be the copy tool on Windows. I've got all platforms using it for consistency.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-ANGLE-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3533
Change-Id: I15f4b63a47121528b2fd2672c26c62765966147c
Reviewed-on: https://skia-review.googlesource.com/3533
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Win-MSVC-x86-Debug-Exceptions-Trybot,Build-Win-MSVC-x86_64-Debug-GN-Trybot,Build-Win-MSVC-x86_64-Release-GN-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3258
Change-Id: Ia2b85904bed1e6ca72c68abaecf6c2854795342c
Reviewed-on: https://skia-review.googlesource.com/3258
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I think I'm now at the point of needing to just resolve missing symbols.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3201
Change-Id: Ib908bd72c23f2d4bafd17182eedcb2fc85c422e5
Reviewed-on: https://skia-review.googlesource.com/3201
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Angle's existing GN files only work in Chrome, so I've written a new one.
This won't work on Windows, but our GN build doesn't work on Windows anyway. So this CL is an attempt to get a ahead of that curve on ANGLE. It looks large but fairly straightforward.
Now working on Linux:
$ gn gen angle --args=skia_use_angle=true
$ ninja -C angle
$ angle/dm --config angle-gl --src gm -w dm-out
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2361983002
Review-Url: https://codereview.chromium.org/2361983002
I trimmed the libmicrohttpd sources and defines down to the minimum needed to build and run. This builds and runs on Linux and Android for me.
Request.h was missing an include for SkTypes.h, which supplies the default for SK_GPU_SUPPORTED if not otherwise defined.
To build on Android, exit() -> _exit().
build.py was unused.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2367513002
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2367513002
Attempt to take over all *SAN builds.
MSAN has a lot of coordination required between gn/BUILD.gn and gn_flavor.py.
I'd like to follow up to move more of this into gn/BUILD.gn, to make it easier
to use locally.
The compile steps should be much faster now. We no longer build CMake
and Clang for every run, instead using the clang_linux CIPD package. This
removes the need for all the third_party/externals/llvm/... dependencies.
Similarly, since we're using the clang_linux package, we no longer depend
on Chrome's Clang, and thus no longer need to sync chromium on these bots.
Instead of packaging up MSAN libraries and llvm-symbolizer in the compile
output, I have the test / perf bots also depend on the clang_linux package.
These do not vary from build to build.
No more need for the xsan.blacklist -include hack: Clang, GN, and Ninja
all track changes to xsan.blacklist without our help.
This has the incidental effect of upgrading the compiler used by *SAN
bots from Clang 3.8 to Clang 3.9.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2289343002
Review-Url: https://codereview.chromium.org/2289343002
Once you have downloaded an android NDK, you can set the ndk GN arg to use it.
E.g. my gn.args looks like:
is_debug = false
ndk = "/opt/android-ndk"
This should be enough to get you going for an arm64 build. You ought to be able to tweak that to other architectures by changing target_cpu to "arm", "x86", "x86-64", etc. That won't quite work until I follow this up a bit, but the skeleton is there.
This is enough to get me compiled, linked, and running to completion on my N5x.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275983004
Review-Url: https://codereview.chromium.org/2275983004
We might as well match the folks who are using our GN files now.
We've got plenty of strategies in our pocket for when we try to move Chrome
onto our GN files (and who knows, there may be even a new better way by then):
* Same sort of rename in Chrome's third_party
* Aliased targets via //build/secondary in Chrome.
* Indirection via build_overrides
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2265503002
Review-Url: https://codereview.chromium.org/2265503002
With the move from SkData::NewXXX to SkData::MakeXXX most
SkAutoTUnref<SkData> were changed to sk_sp<SkData>. However,
there are still a few SkAutoTUnref<SkData> around, so clean
them up.
Review-Url: https://codereview.chromium.org/2212493002
Add nanobench, and while we're at it monobench to show off how cool
source_sets are... the bench files are only built once then linked
into both binaries. With GYP we build them twice. :/ Same deal
for GMs between nanobench and DM... build once, link twice.
nanobench uses SkImageEncoder to encode its .pngs, which requires
we link in the image encoders, which requires we get them all in.
That's the bulk of this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2193513002
Review-Url: https://codereview.chromium.org/2193513002
Hoping to land these using the other GN bots as trybots.
Don't know what magic was letting us get to webp's headers yesterday on Linux. Might have been using /usr/include's ?
The other change is the difference between some setups using #define SK_BUILD_FOR_MAC and others #define SK_BUILD_FOR_MAC 1. We want either to mean "we're Mac".
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2190713004
Review-Url: https://codereview.chromium.org/2190713004
This builds, links, and runs on Linux. Have not tried Mac.
I've tested is_debug={true,false} and is_component_build.
It's neat that the component build DM works, but it's also an indication I've missed an essential flag or two... it shouldn't work. :)
The GPU backend isn't working yet, but all the software configurations I've tried look good.
This fleshes out all the other parts of SkCodec too... I noticed we weren't able to decode gifs or webp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2188643002
Review-Url: https://codereview.chromium.org/2188643002
- Make fiddle build on Mac (skipping GL).
- Now that we're building in SkCodec, we depend on libpng and libjpeg-turbo unconditionally, not just on Linux.
- Re-arrange third_party a bit so that our targets are Fuchsia/Chrome compatible.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2184133002
NOTREECHECKS=true
This doesn't affect Chrome/Blink, so landing through the closed tree.
Review-Url: https://codereview.chromium.org/2184133002
This sketches out what a world without Chrome's GN configs would look like.
Instead of DEPSing in build/, we now host our own gypi_to_gn.py.
The symlink from skia/ to . lets us run gclient hooks when the .gclient file is in the directory above skia/ or inside skia/. That means we don't need gn.py anymore.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2167163002
Review-Url: https://codereview.chromium.org/2167163002
This fixes the build on Linux (dep on third_party:zlib -> third_party/zlib).
I've moved declare_args() {} back to each .gn file... seems like args want
to be as local as possible in GN land.
Additionally, refactor all the common third_party config and warning flag
changes into a template, third_party. This lets it all live together in a
.gni: at head unwanted_configs can be in a .gni (it's just a variable) but
config("no_warnings") (and thus third_party_configs) cannot, as configs
cannot be part of .gni files.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2163653002
Review-Url: https://codereview.chromium.org/2163653002
What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
- add another backend like vs or xcode to GN directly
- intercept via a custom toolchain
- reverse from ninja -t commands
That last option seems kind of fun.
This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
This pulls in some new DEPS:
- build: Chrome's GN configuration, and much more
- buildtools: hashes for gn binary, pulled via hooks
- tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
Have not yet tried building for Windows, Android, or iOS.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17
Review-Url: https://codereview.chromium.org/2087593002
Reason for revert:
gclient not happy on some bots
Original issue's description:
> GN
>
> What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
>
> The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
> - add another backend like vs or xcode to GN directly
> - intercept via a custom toolchain
> - reverse from ninja -t commands
> That last option seems kind of fun.
>
> This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
>
> This pulls in some new DEPS:
> - build: Chrome's GN configuration, and much more
> - buildtools: hashes for gn binary, pulled via hooks
> - tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
> It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
>
> Have not yet tried building for Windows, Android, or iOS.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
>
> Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17TBR=bsalomon@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2088253002
What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
- add another backend like vs or xcode to GN directly
- intercept via a custom toolchain
- reverse from ninja -t commands
That last option seems kind of fun.
This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
This pulls in some new DEPS:
- build: Chrome's GN configuration, and much more
- buildtools: hashes for gn binary, pulled via hooks
- tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
Have not yet tried building for Windows, Android, or iOS.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
Review-Url: https://codereview.chromium.org/2087593002
With this change, the CMake build, which does not use DEPS to sync
external projects, is able to build and use the same version of libpng
that is used in other builds.
This will allow all platforms (including Google3 CMake build) to test on
the same version of libpng, so we do not need to make SkPngCodec support
all versions of libpng.
- Update CMakeLists.txt to use the checked in libpng.
- Check in libpng version 1.6.22rc01
- Update README.google
- Replace our old LICENSE file with the latest one from libpng
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2033063003
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2033063003
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
