Commit Graph

166 Commits

Author SHA1 Message Date
scroggo
f84ad646f9 Reland "Build SkRawCodec in GN"
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
2016-10-31 09:02:57 -07:00
scroggo
2f7068aec9 Treat a GIF with no color table as transparent
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
2016-10-31 04:45:11 -07:00
Leon Scroggins
2ce47630fe Revert "Build SkRawCodec in GN"
This reverts commit 04b1f461aa.

Reason for revert: Breaking build bots


TBR=mtklein@chromium.org,mtklein@google.com,scroggo@google.com,adaubert@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Change-Id: I26c71116ad19b3c494fd632fcc6309bc2ae0d828
Reviewed-on: https://skia-review.googlesource.com/4100
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
2016-10-28 14:09:52 +00:00
Leon Scroggins III
04b1f461aa Build SkRawCodec in GN
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>
2016-10-28 13:46:29 +00:00
scroggo
6fe16d3f58 Remove SkMovie and giflib
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
2016-10-27 12:24:43 -07:00
scroggo
53f63b69e8 Fix decoding GIF to 565
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
2016-10-27 08:29:13 -07:00
scroggo
1285f41395 Write transparent pixels more often (SkGifCodec)
Writing transparent pixels is faster than the alternative, and we can
skip clearing the frame to transparent. We'll still clear if the image
is incomplete.

I ran

  ./out/Release/nanobench --images <images> --samples 100 --sourceType image --simpleCodec -v

over the GIFs we have on our bots, and found an average ~13% speedup.
Raw data is on sheet 2 of
https://docs.google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
(the sheet is named WriteTransparentPixels).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2436183002

Review-Url: https://codereview.chromium.org/2436183002
2016-10-26 13:48:03 -07:00
Jim Van Verth
3cfdf6c8b1 Fix some Windows warnings
BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3980

Change-Id: Icfc5dfb985b966c625d9bc81f61719ac5549085e
Reviewed-on: https://skia-review.googlesource.com/3980
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
2016-10-26 14:16:28 +00:00
scroggo
f9acbe2895 Fix more namespace conflicts in SkGifImageReader
To fix Google3
TBR=benjaminwagner@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2450753003

NOTREECHECKS=true

Review-Url: https://codereview.chromium.org/2450753003
2016-10-25 12:43:21 -07:00
scroggo
b1094bc692 Move third_party/gif's license into its own file
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448573002

Review-Url: https://codereview.chromium.org/2448573002
2016-10-24 13:58:28 -07:00
scroggo
3d3a65c488 Rename GIFImageReader to SkGifImageReader
The former could violate One Definition Rule in Google3, since other
projects that are based on Chrome/webkit also have GIFImageReader.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2445653004

Review-Url: https://codereview.chromium.org/2445653004
2016-10-24 12:28:30 -07:00
scroggo
19b91531e9 Add support for multiple frames in SkCodec
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
2016-10-24 09:03:26 -07:00
Jim Van Verth
4e56a91393 Add Android viewer to GN
BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3761

Change-Id: If971e275ed377cd733d01f62622d408479632465
Reviewed-on: https://skia-review.googlesource.com/3761
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2016-10-21 15:19:32 +00:00
Mike Klein
43c2526665 Viewer on Mac.
- 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>
2016-10-20 14:57:49 +00:00
Mike Klein
a2c2fdd49b GN: ANGLE build completes now on Windows
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>
2016-10-17 16:45:39 +00:00
Mike Klein
1a8d675148 GN: get Angle compiling on Windows.
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>
2016-10-17 16:16:16 +00:00
Mike Klein
c7165c239a GN/Win: warnings and warn-as-error
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>
2016-10-13 04:17:38 +00:00
Mike Klein
2148052ebc GN/Win: everything links on my machine.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3267

Change-Id: I9879e3e33104a4eea6e5a87573a1b081dcc5ed54
Reviewed-on: https://skia-review.googlesource.com/3267
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2016-10-12 16:39:42 +00:00
Mike Klein
4b167fc850 GN/Win: everything but skiaserve links.
BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3240

Change-Id: I85c306f89f3a7faa7f50dadf465122844d015604
Reviewed-on: https://skia-review.googlesource.com/3240
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2016-10-11 22:37:40 +00:00
Mike Klein
3eb71216d2 More steps toward GN/Windows.
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>
2016-10-11 21:31:19 +00:00
Mike Klein
0f61faa7b7 GN: windows compiles locally.
Not yet linking.  Ignoring bots for now.

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3200

Change-Id: Idd75033313df60844c2ba602f7845b3c52987bc2
Reviewed-on: https://skia-review.googlesource.com/3200
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2016-10-11 20:48:25 +00:00
benjaminwagner
2b7394b9fb Fix obvious bug in KTX encoder.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2383523002

Review-Url: https://codereview.chromium.org/2383523002
2016-09-29 08:20:41 -07:00
mtklein
d68f9b0038 GN: ANGLE
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
2016-09-23 13:18:41 -07:00
mtklein
ecbc526418 GN: build skiaserve
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
2016-09-22 11:51:24 -07:00
herb
b6318bf44d Compile the skia library for windows using gn.
TBR=mtklein@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347443002

Review-Url: https://codereview.chromium.org/2347443002
2016-09-16 13:29:57 -07:00
mtklein
2b3c2a3ff9 GN: add sanitize arg
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
2016-09-08 08:39:34 -07:00
hcm
005327b9dd BUG=skia:5602
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302913002

Review-Url: https://codereview.chromium.org/2302913002
2016-09-02 11:19:34 -07:00
bungeman
41a8f323f7 Update FreeType dependency from 2.6.1 to 2.6.5.
- 6a19a7d332c5446542196e5aeda0ede109ef097b
+ 4d3f7ca8cedbddad40b9e93a82926618e3fb4265

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302493002

Review-Url: https://codereview.chromium.org/2302493002
2016-08-31 12:48:18 -07:00
mtklein
349cecefe2 GN: mac host and armv7 target
Just when I thought it wouldn't be useful to override ar...

Tested by building 32- and 64-bit DM on my MBP and running it on my N5x.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2279703003

Review-Url: https://codereview.chromium.org/2279703003
2016-08-26 08:13:04 -07:00
mtklein
7d6fb2c92d GN: Android
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
2016-08-25 14:50:44 -07:00
mtklein
0a8efd7355 GN: _turbo -> -turbo to match Fuchsia
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
2016-08-22 06:32:39 -07:00
mtklein
3896effcad GN: make libjpeg_turbo target Chrome-compatible
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2257903002

Review-Url: https://codereview.chromium.org/2257903002
2016-08-18 12:04:13 -07:00
jvanverth
1ba1d372c2 Get Mac viewer working with SDL
Also fixes SkiaSDLExample.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2210603003

Review-Url: https://codereview.chromium.org/2210603003
2016-08-04 12:30:31 -07:00
mtklein
7a1f45f9e5 spin off easy stuff from Herb's windows GN CL
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2209533004

No public API changes.
TBR=reed@google.com

Review-Url: https://codereview.chromium.org/2209533004
2016-08-04 06:19:33 -07:00
halcanary
19a9720978 GN: build sfntly, icu, harfbuzz
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2200833010

Review-Url: https://codereview.chromium.org/2200833010
2016-08-03 15:08:04 -07:00
bungeman
ffae30db4a Convert SkAutoTUnref<SkData> to sk_sp<SkData>.
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
2016-08-03 13:32:32 -07:00
mtklein
7c1ae7af4f GN: add some missing SkCodec defines
TURBO_HAS_...
    WEBP_SWAP_16BIT_CSP

BUG=skia:5591
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2196413003

Review-Url: https://codereview.chromium.org/2196413003
2016-08-01 15:50:27 -07:00
mtklein
2b6870ccb2 GN: nanobench
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
2016-07-28 14:17:33 -07:00
mtklein
0634317cbe GN: fix mac build again
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
2016-07-28 09:58:44 -07:00
mtklein
25c81d4e65 GN: dm
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
2016-07-27 13:55:27 -07:00
mtklein
7d10b9f6e6 GN: fixes for Mac
- 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
2016-07-27 11:17:18 -07:00
halcanary
aa7f67c76b DEPS: harfbuzz 1.2.7 → 1.3.0
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2179963005

Review-Url: https://codereview.chromium.org/2179963005
2016-07-27 10:08:39 -07:00
msarett
ae76f49a76 Make yasm-android executable
TBR=mtklein@google.com
NOTRY=true
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2188583002

Review-Url: https://codereview.chromium.org/2188583002
2016-07-26 13:46:16 -07:00
msarett
75a5ff63f7 Rename yasm binary and make it executable
TBR=mtklein@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2187663002

Review-Url: https://codereview.chromium.org/2187663002
2016-07-26 13:33:46 -07:00
msarett
dc2257bfab Fix yasm for Android build
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180333002

Review-Url: https://codereview.chromium.org/2180333002
2016-07-26 11:24:28 -07:00
mtklein
7fbfbbe8f4 Basic standalone GN configs.
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
2016-07-21 12:25:45 -07:00
mtklein
f037d48e29 GN: refactor third_party/gni
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
2016-07-19 08:25:00 -07:00
abarth
6fc8ff024b Add support for Fuchsia
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2152273002

[mtklein edit from here down]
No public API changes.
TBR=reed@google.com

Review-Url: https://codereview.chromium.org/2152273002
2016-07-15 15:15:15 -07:00
mtklein
c04ff4788c 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/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17
Review-Url: https://codereview.chromium.org/2087593002
2016-06-23 10:29:30 -07:00
mtklein
3917cf4ef7 Revert of GN (patchset #12 id:220001 of 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/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17

TBR=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
2016-06-22 10:07:07 -07:00