aboutsummaryrefslogtreecommitdiffhomepage
path: root/gyp/pathops_skpclip.gyp
Commit message (Collapse)AuthorAge
* add -Iinclude/private anywhere we have -Isrc/coreGravatar mtklein2015-07-28
| | | | | | | | | | | | | | | I'll be moving headers from src/core to include/private, so this guarantees that anyone who was finding them via -Isrc/core can now find them via -Iinclude/private. This is purely mechanical, mostly to preserve my sanity, so it's likely (harmless) overkill. Chromium's GYP and GN builds already set -Iinclude/private for Skia builds. BUG=skia:4126 Review URL: https://codereview.chromium.org/1265443002
* Add copyright headers to remaining gyp files.Gravatar scroggo2015-03-25
| | | | | | | | Prevents some PRESUBMIT errors. TBR=mtklein@google.com Review URL: https://codereview.chromium.org/1035523003
* Turn SkTaskGroups back on.Gravatar mtklein2014-11-03
| | | | | | | | | | | | | Revert "Disable SkTaskGroup in SkMultiPictureDraw temporarily." Revert "Revert harder, removing SkTaskGroup.cpp from core temporarily." NOTREECHECKS=true BUG=skia: Committed: https://skia.googlesource.com/skia/+/2100c5ed7a5e5470a04e7af7309d8bd3fc4249f7 Review URL: https://codereview.chromium.org/687263007
* Revert of Turn SkTaskGroups back on. (patchset #1 id:1 of ↵Gravatar mtklein2014-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/687263007/) Reason for revert: precautionary revert. may have caused WinXP crashes on Chrome tree: https://code.google.com/p/chromium/issues/detail?id=429207 Original issue's description: > Turn SkTaskGroups back on. > > Revert "Disable SkTaskGroup in SkMultiPictureDraw temporarily." > Revert "Revert harder, removing SkTaskGroup.cpp from core temporarily." > > NOTREECHECKS=true > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/2100c5ed7a5e5470a04e7af7309d8bd3fc4249f7 TBR=reed@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/693993002
* Turn SkTaskGroups back on.Gravatar mtklein2014-10-31
| | | | | | | | | | | Revert "Disable SkTaskGroup in SkMultiPictureDraw temporarily." Revert "Revert harder, removing SkTaskGroup.cpp from core temporarily." NOTREECHECKS=true BUG=skia: Review URL: https://codereview.chromium.org/687263007
* Revert harder, removing SkTaskGroup.cpp from core temporarily.Gravatar mtklein2014-10-30
| | | | | | | | | Not all linkers are seeing the SkThread code is not needed. BUG=skia: NOTREECHECKS=true Review URL: https://codereview.chromium.org/673903007
* MultiPictureDraw is taskgroup aware.Gravatar reed2014-10-29
| | | | | | | | SampleApp is multipicturedraw aware. BUG=skia: Review URL: https://codereview.chromium.org/684923002
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of ↵Gravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/531653002/) Reason for revert: Leaks, leaks, leaks. Original issue's description: > SkThreadPool ~~> SkTaskGroup > > SkTaskGroup is like SkThreadPool except the threads stay in > one global pool. Each SkTaskGroup itself is tiny (4 bytes) > and its wait() method applies only to tasks add()ed to that > instance, not the whole thread pool. > > This means we don't need to bring up new thread pools when > tests themselves want to use multithreading (e.g. pathops, > quilt). We just create a new SkTaskGroup and wait for that > to complete. This should be more efficient, and allow us > to expand where we use threads to really latency sensitive > places. E.g. we can probably now use these in nanobench > for CPU .skp rendering. > > Now that all threads are sharing the same pool, I think we > can remove most of the custom mechanism pathops tests use > to control threading. They'll just ride on the global pool > with all other tests now. > > This (temporarily?) removes the GPU multithreading feature > from DM, which we don't use. > > On my desktop, DM runs a little faster (57s -> 55s) in > Debug, and a lot faster in Release (36s -> 24s). The bots > show speedups of similar proportions, cutting more than a > minute off the N4/Release and Win7/Debug runtimes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Author: mtklein@google.com Review URL: https://codereview.chromium.org/533393002
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* update pathops core and testsGravatar caryclark2014-07-18
split out skpclip (the test of 1M pictures) into its own project TBR=reed Author: caryclark@google.com Review URL: https://codereview.chromium.org/400033002
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-16 09:05:40 +0000