aboutsummaryrefslogtreecommitdiffhomepage
path: root/third_party
Commit message (Collapse)AuthorAge
...
* SkXbyak basicsGravatar Mike Klein2017-01-06
| | | | | | | | | | | | 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>
* GIF: Better check for frame dependencyGravatar Leon Scroggins III2017-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make SkGIFLZWBlock modifiable so it is assignableGravatar Chris Blume2016-12-21
| | | | | | | | | | | | | 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>
* GIF: Avoid copying/storing data when possibleGravatar Leon Scroggins III2016-12-19
| | | | | | | | | | | | | | | | | | | 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>
* Revert "Remove all KTX support"Gravatar Leon Scroggins2016-12-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit ada12ab0557a1f540e775288e2ce44f64fcd8c7e. 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>
* Remove all KTX supportGravatar Leon Scroggins III2016-12-15
| | | | | | | | | | 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>
* Do not create SkGifCodec if true size is not knownGravatar Leon Scroggins III2016-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Roll third_party/externals/freetype 4d3f7ca8cedb..ffd8f622360Gravatar Ben Wagner2016-12-08
| | | | | | | | | https://skia.googlesource.com/third_party/freetype2.git/+log/4d3f7ca8cedb..ffd8f622360 Change-Id: Ia9d8af09253d0aff343c2310f5eb8c934b2ebbda Reviewed-on: https://skia-review.googlesource.com/5685 Reviewed-by: Derek Sollenberger <djsollen@google.com> Commit-Queue: Ben Wagner <bungeman@google.com>
* GIF: Internal cleanup - remove color map parameterGravatar Leon Scroggins III2016-12-05
| | | | | | | | | | | | | 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>
* third_party/ktx: put WriteBitmapToKTX backGravatar Hal Canary2016-12-01
| | | | | | | | | 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>
* SkEncodeImage: no more link-time registrationGravatar Hal Canary2016-11-30
| | | | | | | | | | | | | | | 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>
* Apple's Clang can't assemble jsimd_arm_...Gravatar Mike Klein2016-11-14
| | | | | | | | | | | 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>
* GN: turn on easy libjpeg-turbo SIMD backends (ARMv7 and ARMv8)Gravatar Mike Klein2016-11-14
| | | | | | | | | | | | | | | | | | | 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>
* GN: build Lua tools when skia_use_lua.Gravatar Mike Klein2016-11-11
| | | | | | | | | | | | | | | | | 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>
* GN: turn on libpng SSE2 filtersGravatar Mike Klein2016-11-07
| | | | | | | | | | | | | | | | | 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>
* Write transparent pixels more often in SkGifImageReaderGravatar Matt Sarett2016-11-03
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Delete qcmsGravatar Matt Sarett2016-11-01
| | | | | | | | | | | | | | | | | | | | 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>
* Allow most third_party targets to use system libraries if asked.Gravatar Mike Klein2016-11-01
| | | | | | | | | | | | | | | | | 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>
* Report repetition count in SkCodecGravatar scroggo2016-11-01
| | | | | | | | | | | | | | | | | | | | | 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
* Reland "Build SkRawCodec in GN"Gravatar scroggo2016-10-31
| | | | | | | | | | | | | | | | 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
* Treat a GIF with no color table as transparentGravatar scroggo2016-10-31
| | | | | | | | | | | | | | | 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
* Revert "Build SkRawCodec in GN"Gravatar Leon Scroggins2016-10-28
| | | | | | | | | | | | | | | | | This reverts commit 04b1f461aa49c91ffbc484b88b32489efca55bab. 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>
* Build SkRawCodec in GNGravatar Leon Scroggins III2016-10-28
| | | | | | | | | | | | | | | | | | 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>
* Remove SkMovie and giflibGravatar scroggo2016-10-27
| | | | | | | | | | | | | | | 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
* Fix decoding GIF to 565Gravatar scroggo2016-10-27
| | | | | | | | | | | | 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
* Write transparent pixels more often (SkGifCodec)Gravatar scroggo2016-10-26
| | | | | | | | | | | | | | | | | | 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
* Fix some Windows warningsGravatar Jim Van Verth2016-10-26
| | | | | | | | | | | 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>
* Fix more namespace conflicts in SkGifImageReaderGravatar scroggo2016-10-25
| | | | | | | | | | 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
* Move third_party/gif's license into its own fileGravatar scroggo2016-10-24
| | | | | | GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448573002 Review-Url: https://codereview.chromium.org/2448573002
* Rename GIFImageReader to SkGifImageReaderGravatar scroggo2016-10-24
| | | | | | | | 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
* Add support for multiple frames in SkCodecGravatar scroggo2016-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add Android viewer to GNGravatar Jim Van Verth2016-10-21
| | | | | | | | | | | 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>
* Viewer on Mac.Gravatar Mike Klein2016-10-20
| | | | | | | | | | | | | | | | | - 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>
* GN: ANGLE build completes now on WindowsGravatar Mike Klein2016-10-17
| | | | | | | | | | | 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>
* GN: get Angle compiling on Windows.Gravatar Mike Klein2016-10-17
| | | | | | | | | | | | | | | | | | 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>
* GN/Win: warnings and warn-as-errorGravatar Mike Klein2016-10-13
| | | | | | | | | | | 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>
* GN/Win: everything links on my machine.Gravatar Mike Klein2016-10-12
| | | | | | | | | 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>
* GN/Win: everything but skiaserve links.Gravatar Mike Klein2016-10-11
| | | | | | | | | | | 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>
* More steps toward GN/Windows.Gravatar Mike Klein2016-10-11
| | | | | | | | | | | 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>
* GN: windows compiles locally.Gravatar Mike Klein2016-10-11
| | | | | | | | | | | 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>
* Fix obvious bug in KTX encoder.Gravatar benjaminwagner2016-09-29
| | | | | | | BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2383523002 Review-Url: https://codereview.chromium.org/2383523002
* GN: ANGLEGravatar mtklein2016-09-23
| | | | | | | | | | | | | | | | 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
* GN: build skiaserveGravatar mtklein2016-09-22
| | | | | | | | | | | | | | | | | 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
* Compile the skia library for windows using gn.Gravatar herb2016-09-16
| | | | | | | | TBR=mtklein@google.com BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347443002 Review-Url: https://codereview.chromium.org/2347443002
* GN: add sanitize argGravatar mtklein2016-09-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* BUG=skia:5602Gravatar hcm2016-09-02
| | | | | | GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302913002 Review-Url: https://codereview.chromium.org/2302913002
* Update FreeType dependency from 2.6.1 to 2.6.5.Gravatar bungeman2016-08-31
| | | | | | | | | - 6a19a7d332c5446542196e5aeda0ede109ef097b + 4d3f7ca8cedbddad40b9e93a82926618e3fb4265 GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302493002 Review-Url: https://codereview.chromium.org/2302493002
* GN: mac host and armv7 targetGravatar mtklein2016-08-26
| | | | | | | | | | | 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
* GN: AndroidGravatar mtklein2016-08-25
| | | | | | | | | | | | | | | | 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
* GN: _turbo -> -turbo to match FuchsiaGravatar mtklein2016-08-22
| | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-08 23:04:42 +0000