aboutsummaryrefslogtreecommitdiffhomepage
path: root/tests/PathOpsThreadedCommon.h
Commit message (Collapse)AuthorAge
* clean up more dead codeGravatar mtklein2016-02-16
| | | | | | | | | | - SkSHA1 is unused - SkRunnable is obsolete now that we have std::function BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1705583003 Review URL: https://codereview.chromium.org/1705583003
* C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}Gravatar mtklein2015-03-25
| | | | | | | | | NOPRESUBMIT=true BUG=skia: DOCS_PREVIEW= https://skia.org/?cl=1037793002 Review URL: https://codereview.chromium.org/1037793002
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | This fixes every case where virtual and SK_OVERRIDE were on the same line, which should be the bulk of cases. We'll have to manually clean up the rest over time unless I level up in regexes. for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end BUG=skia: Review URL: https://codereview.chromium.org/806653007
* 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
* pathops work in progressGravatar caryclark@google.com2013-11-01
| | | | | | | | BUG= Review URL: https://codereview.chromium.org/52653002 git-svn-id: http://skia.googlecode.com/svn/trunk@12089 2bbb7eff-a529-9590-31e7-b0007b416f81
* path ops work in progressGravatar caryclark@google.com2013-10-02
| | | | | | | | | | | | make more skps work remove edit files BUG= Review URL: https://codereview.chromium.org/23542056 git-svn-id: http://skia.googlecode.com/svn/trunk@11570 2bbb7eff-a529-9590-31e7-b0007b416f81
* path ops work in progressGravatar caryclark@google.com2013-07-08
| | | | | | | | BUG= Review URL: https://codereview.chromium.org/18058007 git-svn-id: http://skia.googlecode.com/svn/trunk@9908 2bbb7eff-a529-9590-31e7-b0007b416f81
* path ops -- fix skp bugsGravatar caryclark@google.com2013-05-07
| | | | | | | | | This fixes a series of bugs discovered by running the small set of Skia skp files through pathops to flatten the clips. Review URL: https://codereview.chromium.org/14798004 git-svn-id: http://skia.googlecode.com/svn/trunk@9042 2bbb7eff-a529-9590-31e7-b0007b416f81
* path ops : remove countdown overkillGravatar caryclark@google.com2013-04-18
| | | | | | Review URL: https://codereview.chromium.org/13958005 git-svn-id: http://skia.googlecode.com/svn/trunk@8756 2bbb7eff-a529-9590-31e7-b0007b416f81
* path ops work in progressGravatar caryclark@google.com2013-04-18
| | | | | | | | | fix bugs in tests on 32 bit release Most changes revolve around pinning computed t values very close to zero and one. git-svn-id: http://skia.googlecode.com/svn/trunk@8745 2bbb7eff-a529-9590-31e7-b0007b416f81
* fix a few pathops test bugs exposed on Mac and LinuxGravatar caryclark@google.com2013-04-10
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@8601 2bbb7eff-a529-9590-31e7-b0007b416f81
* Make parallel unit testing work on windowsGravatar caryclark@google.com2013-04-10
Review URL: https://codereview.chromium.org/14072002 git-svn-id: http://skia.googlecode.com/svn/trunk@8594 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 20:17:20 +0000