aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/utils
Commit message (Collapse)AuthorAge
* add more typeface methods to luaGravatar reed2014-11-04
| | | | | | | | BUG=skia: NOTRY=True TBR= Review URL: https://codereview.chromium.org/697053004
* update slide contentGravatar reed2014-11-03
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/698563004
* add textblobs to luaGravatar reed2014-11-03
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/688363003
* Manually load CONDITION_VARIABLE methods on Windows, checking for failure (XP).Gravatar mtklein2014-11-03
| | | | | | | | | | | | Tested by running DM on XP. Before this patch, it fails at startup (even just out/Debug/dm --help). Now it asserts for other reasons later on in user code, which is just fine by me. The net effect is that SkTaskGroups will always be synchronous on XP. That's not ideal, but a step up from crashing. CQ_EXTRA_TRYBOTS=client.skia:Test-Win7-ShuttleA-HD2000-x86-Release-Trybot,Test-Win7-ShuttleA-HD2000-x86_64-Release-Trybot BUG=skia: Review URL: https://codereview.chromium.org/700683002
* move SkTextBox into utilsGravatar reed2014-11-03
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/696293005
* MultiPictureDraw is taskgroup aware.Gravatar reed2014-10-29
| | | | | | | | SampleApp is multipicturedraw aware. BUG=skia: Review URL: https://codereview.chromium.org/684923002
* SkTaskGroup::add(fn, arg)Gravatar mtklein2014-10-29
| | | | | | | | NOTREECHECKS=true BUG=skia: Review URL: https://codereview.chromium.org/687953003
* Override SkCanvas::drawImage[Rect]() in SkProxyCanvasGravatar piotaixr2014-10-28
| | | | | | BUG=skia:2947 Review URL: https://codereview.chromium.org/679293002
* In SkPDFDocumentToBitmap, use SkCreateDataProviderFromStreamGravatar halcanary2014-10-27
| | | | | | | CGDataProviderCreateWithData to SkCreateDataProviderFromStream in SkPDFDocumentToBitmap Review URL: https://codereview.chromium.org/678763003
* add saveLayer to luaGravatar reed2014-10-25
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/679903002
* Add utils to better quantize grayscale values to three bit indices whileGravatar pavel2014-10-23
| | | | | | | | | | compressing coverage masks. Signed-off-by: Pavel Krajcevski <pavel@cs.unc.edu> BUG=skia: Review URL: https://codereview.chromium.org/669243003
* Override SkCanvas::drawImage() in SkDeferredCanvas and SkGPipeGravatar piotaixr2014-10-22
| | | | | | | | | | Depend on https://codereview.chromium.org/663233002 BUG=skia:2947 Committed: https://skia.googlesource.com/skia/+/687732fe046c9cfec940f2d7f661cd97651d10a8 Review URL: https://codereview.chromium.org/613673005
* Fix debugger's SaveAs functionalityGravatar robertphillips2014-10-21
| | | | | | Without this patch the SaveAs functionality only copies the portion of the picture from the current command in the GUI. Review URL: https://codereview.chromium.org/672453002
* Check SkStream::isAtEnd before attempting to read.Gravatar scroggo2014-10-21
| | | | | | | | | | In FrontBufferedStream, when attempting to read and buffer more data, do not try to read if the underlying stream is at the end. Prevents a bug where we continue trying to read a stream that has nothing more to read. Review URL: https://codereview.chromium.org/665303002
* add gradients and drawPaint to luaGravatar reed2014-10-21
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/667803004
* Add an assert that we still have a buffer to readFromBuffer().Gravatar mtklein2014-10-21
| | | | | | | | sk_free(fBuffer.detach()) means fBuffer will be left as NULL, not a zero-length malloc. BUG=skia: Review URL: https://codereview.chromium.org/669813002
* add blurimagefilter to luaGravatar reed2014-10-19
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/663993002
* Revert of Override SkCanvas::drawImage() in SkDeferredCanvas and SkGPipe ↵Gravatar rmistry2014-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #5 id:80001 of https://codereview.chromium.org/613673005/) Reason for revert: Trying to fix DEPS roll failure: https://codereview.chromium.org/660113002/ Link to failing builds: http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/29578 http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/29354 Original issue's description: > Override SkCanvas::drawImage() in SkDeferredCanvas and SkGPipe > > BUG=skia:2947 > > Committed: https://skia.googlesource.com/skia/+/687732fe046c9cfec940f2d7f661cd97651d10a8 TBR=junov@chromium.org,reed@google.com,bsalomon@chromium.org,piotaixr@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia:2947 Review URL: https://codereview.chromium.org/658293004
* "Fix" debugger's setMatrix handlingGravatar robertphillips2014-10-16
| | | | | | | | | | This remedies two problems with the debugger's matrix handling: 1) the user matrix was not being passed to the setMatrix command (for a concat) 2) the setting of the user matrix was not consistently forcing a complete re-rendering of the scene BUG=skia:3018 Review URL: https://codereview.chromium.org/660883002
* Override SkCanvas::drawImage() in SkDeferredCanvas and SkGPipeGravatar piotaixr2014-10-16
| | | | | | BUG=skia:2947 Review URL: https://codereview.chromium.org/613673005
* create and modify matrices in luaGravatar reed2014-10-14
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/651823004
* add pictures to luaGravatar reed2014-10-13
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/650263002
* add canvas:clear to luaGravatar reed2014-10-12
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/648083002
* add surfaces to luaGravatar reed2014-10-12
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/649973002
* add key handlers to luaGravatar reed2014-10-11
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/652473002
* add drawImageRect to lua, update sampleGravatar reed2014-10-10
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/642353005
* Small improvements to SkBitSet:Gravatar mtklein2014-10-09
| | | | | | | | | | - implement O(1) operations in SkBitSet.h so they can inline away - use calloc to allocate empty bitsets instead of malloc then clear - little style things BUG=skia: Review URL: https://codereview.chromium.org/640243003
* Restore a really single-threaded mode to DM.Gravatar mtklein2014-10-06
| | | | | | | | | | | | | | | Used to be: 0 -> run on main thread plus an autodetected number of extra threads (default) N -> run on main thread plus N extra threads Now it's: -1 -> run on main thread plus an autodetected number of extra threads (default) 0 -> run on main thread N -> run on main thread plus N extra threads BUG=skia: Review URL: https://codereview.chromium.org/636593002
* Override drawImage*() in SkNWayCanvasGravatar piotaixr2014-09-29
| | | | | | | | | BUG=skia:2947 R=junov@chromium.org, reed@google.com, bsalomon@chromium.org Author: piotaixr@chromium.org Review URL: https://codereview.chromium.org/600643002
* Revert of Revert of Fix SkTextBlob offset semantics. (patchset #1 id:1 of ↵Gravatar fmalita2014-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/609223003/) Reason for revert: Re-landing: Chromium-side fix to be landed with the roll (https://codereview.chromium.org/607853003/) Original issue's description: > Revert of Fix SkTextBlob offset semantics. (patchset #2 id:20001 of https://codereview.chromium.org/605533002/) > > Reason for revert: > Breaking the Chrome builds with the error: > > [14:54:14.317833] ../../skia/ext/pixel_ref_utils.cc:221:16: error: 'drawPosText' marked 'override' but does not override any member functions > [14:54:14.318022] virtual void drawPosText(const SkDraw& draw, > [14:54:14.318082] ^ > > Original issue's description: > > Fix SkTextBlob offset semantics. > > > > Implement proper x/y drawTextBlob() handling by plumbing a > > drawPosText() offset parameter (to act as an additional glyph pos > > translation) throughout the device layer. > > > > The new offset superceeds the existing constY, with a minor semantic > > tweak: whereas previous implementations were ignoring constY in 2D > > positioning mode (scalarsPerGlyph == 2), now the offset is always > > observed, in all positioning modes. We can do this because existing > > drawPosText() clients always pass constY == 0 for full positioning mode. > > > > R=reed@google.com, jvanverth@google.com, robertphillips@google.com > > > > Committed: https://skia.googlesource.com/skia/+/c13bc571d3e61a43b87eb97f0719abd304cafaf2 > > TBR=jvanverth@google.com,reed@google.com,bsalomon@google.com,fmalita@chromium.org > NOTREECHECKS=true > NOTRY=true > > Committed: https://skia.googlesource.com/skia/+/d46b8d2bab7cfba8458432248e1568ac377429e9 R=jvanverth@google.com, reed@google.com, bsalomon@google.com, robertphillips@google.com TBR=bsalomon@google.com, jvanverth@google.com, reed@google.com, robertphillips@google.com NOTREECHECKS=true NOTRY=true Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/607413003
* Revert of Fix SkTextBlob offset semantics. (patchset #2 id:20001 of ↵Gravatar robertphillips2014-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/605533002/) Reason for revert: Breaking the Chrome builds with the error: [14:54:14.317833] ../../skia/ext/pixel_ref_utils.cc:221:16: error: 'drawPosText' marked 'override' but does not override any member functions [14:54:14.318022] virtual void drawPosText(const SkDraw& draw, [14:54:14.318082] ^ Original issue's description: > Fix SkTextBlob offset semantics. > > Implement proper x/y drawTextBlob() handling by plumbing a > drawPosText() offset parameter (to act as an additional glyph pos > translation) throughout the device layer. > > The new offset superceeds the existing constY, with a minor semantic > tweak: whereas previous implementations were ignoring constY in 2D > positioning mode (scalarsPerGlyph == 2), now the offset is always > observed, in all positioning modes. We can do this because existing > drawPosText() clients always pass constY == 0 for full positioning mode. > > R=reed@google.com, jvanverth@google.com, robertphillips@google.com > > Committed: https://skia.googlesource.com/skia/+/c13bc571d3e61a43b87eb97f0719abd304cafaf2 R=jvanverth@google.com, reed@google.com, bsalomon@google.com, fmalita@chromium.org TBR=bsalomon@google.com, fmalita@chromium.org, jvanverth@google.com, reed@google.com NOTREECHECKS=true NOTRY=true Author: robertphillips@google.com Review URL: https://codereview.chromium.org/609223003
* SkMatrix44::preserves2dAxisAlignment()Gravatar tomhudson2014-09-26
| | | | | | | | | | | | Convenience function requested for Chrome compositor that may have a performance advantage. BUG=skia:1017 R=reed@google.com, danakj@chromium.org, vollick@chromium.org Author: tomhudson@google.com Review URL: https://codereview.chromium.org/508303005
* Fix SkTextBlob offset semantics.Gravatar Florin Malita2014-09-26
| | | | | | | | | | | | | | | | Implement proper x/y drawTextBlob() handling by plumbing a drawPosText() offset parameter (to act as an additional glyph pos translation) throughout the device layer. The new offset superceeds the existing constY, with a minor semantic tweak: whereas previous implementations were ignoring constY in 2D positioning mode (scalarsPerGlyph == 2), now the offset is always observed, in all positioning modes. We can do this because existing drawPosText() clients always pass constY == 0 for full positioning mode. R=reed@google.com, jvanverth@google.com, robertphillips@google.com Review URL: https://codereview.chromium.org/605533002
* SkCanvas::drawImage is the new way for drawing a SkImage to a CanvasGravatar piotaixr2014-09-24
| | | | | | | | | | | | BUG=skia:2947 Committed: https://skia.googlesource.com/skia/+/432789972c1e1f8a66165c75a250dba1853efa08 R=junov@chromium.org, reed@google.com, bsalomon@google.com Author: piotaixr@chromium.org Review URL: https://codereview.chromium.org/583453002
* Revert of SkCanvas::drawImage is the new way for drawing an SkImage to a ↵Gravatar borenet2014-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | Canvas (patchset #9 id:160001 of https://codereview.chromium.org/583453002/) Reason for revert: Broke ChromiumOS Ozone builder: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Ozone%20Builder/builds/4087/steps/compile/logs/stdio Reverting to unblock DEPS roll. Original issue's description: > SkCanvas::drawImage is the new way for drawing a SkImage to a Canvas > > BUG=skia:2947 > > Committed: https://skia.googlesource.com/skia/+/432789972c1e1f8a66165c75a250dba1853efa08 R=junov@chromium.org, reed@google.com, bsalomon@google.com, piotaixr@chromium.org TBR=bsalomon@google.com, junov@chromium.org, piotaixr@chromium.org, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2947 Author: borenet@google.com Review URL: https://codereview.chromium.org/598133002
* SkCanvas::drawImage is the new way for drawing a SkImage to a CanvasGravatar piotaixr2014-09-23
| | | | | | | | | BUG=skia:2947 R=junov@chromium.org, reed@google.com, bsalomon@google.com Author: piotaixr@chromium.org Review URL: https://codereview.chromium.org/583453002
* Introduce Props to surface (patchset #27 id:520001 of ↵Gravatar reed2014-09-22
| | | | | | | | | | | | https://codereview.chromium.org/551463004/)" This reverts commit 29c857d0f3a1cb837f73406eeb6ba9771879b5e7. TBR= Author: reed@google.com Review URL: https://codereview.chromium.org/588143004
* Revert of introduce Props to surface (patchset #27 id:520001 of ↵Gravatar reed2014-09-21
| | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/551463004/) Reason for revert: Broke call site in WebKit Original issue's description: > introduce Props to surface (work in progress) > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/3716fd067a5621bb94a6cb08d72afec8bf3aceda R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@google.com TBR=bsalomon@google.com, bungeman@google.com, fmalita@google.com, jvanverth@google.com, reed@google.com, robertphillips@google.com, vangelis@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Author: reed@chromium.org Review URL: https://codereview.chromium.org/583773004
* introduce Props to surface (work in progress)Gravatar reed2014-09-21
| | | | | | | | | BUG=skia: R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/551463004
* Use SkImage::NewFromGenerator() instead of SkImage::newEncodedData()Gravatar piotaixr2014-09-17
| | | | | | | | | BUG=skia:2948 R=junov@chromium.org, reed@google.com Author: piotaixr@chromium.org Review URL: https://codereview.chromium.org/575173002
* Picture Recording: fix the performance bottleneck in ↵Gravatar yunchao.he2014-09-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkDeferredCanvas::isFullFrame blink skips all pending commands during picture recording if it is drawing an opaque full-frame geometry or image. This may improve performance for some edge cases. To recognize an opaque full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement. Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process. benchmark percentage my local benchmark(draw 1000 sprites) 4.1% speedReading 2.8% FishIETank(1000 fishes) 1.5% GUIMark3 Bitmap 2.0% By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization (GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently, SkDeferredCanvas::isFullFrame() is nontrivial. getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times) of isFullFrame(). telemetry smoothness canvas_tough_test didn't show obvious improvement or regression. BUG=411166 Committed: https://skia.googlesource.com/skia/+/8e45c3777d886ba3fe239bb549d06b0693692152 R=junov@chromium.org, tomhudson@google.com, reed@google.com Author: yunchao.he@intel.com Review URL: https://codereview.chromium.org/545813002
* Revert of Picture Recording: fix the performance bottleneck in ↵Gravatar mtklein2014-09-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkDeferredCanvas::isFullFrame (patchset #7 id:140001 of https://codereview.chromium.org/545813002/) Reason for revert: This is leaking memory: http://108.170.220.120:10117/builders/Test-Ubuntu13.10-GCE-NoGPU-x86_64-Debug-ASAN/builds/2516/steps/RunDM/logs/stdio Original issue's description: > Picture Recording: fix the performance bottleneck in SkDeferredCanvas::isFullFrame > > blink skips all pending commands during picture recording if it is drawing an opaque full-frame > geometry or image. This may improve performance for some edge cases. To recognize an opaque > full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement. > Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame > is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process. > > benchmark percentage > my local benchmark(draw 1000 sprites) 4.1% > speedReading 2.8% > FishIETank(1000 fishes) 1.5% > GUIMark3 Bitmap 2.0% > > By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization > (GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently, > SkDeferredCanvas::isFullFrame() is nontrivial. > > getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and > reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times) > of isFullFrame(). > > telemetry smoothness canvas_tough_test didn't show obvious improvement or regression. > > BUG=411166 > > Committed: https://skia.googlesource.com/skia/+/8e45c3777d886ba3fe239bb549d06b0693692152 R=junov@chromium.org, tomhudson@google.com, reed@google.com, yunchao.he@intel.com TBR=junov@chromium.org, reed@google.com, tomhudson@google.com, yunchao.he@intel.com NOTREECHECKS=true NOTRY=true BUG=411166 Author: mtklein@google.com Review URL: https://codereview.chromium.org/571053002
* Picture Recording: fix the performance bottleneck in ↵Gravatar yunchao.he2014-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkDeferredCanvas::isFullFrame blink skips all pending commands during picture recording if it is drawing an opaque full-frame geometry or image. This may improve performance for some edge cases. To recognize an opaque full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement. Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process. benchmark percentage my local benchmark(draw 1000 sprites) 4.1% speedReading 2.8% FishIETank(1000 fishes) 1.5% GUIMark3 Bitmap 2.0% By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization (GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently, SkDeferredCanvas::isFullFrame() is nontrivial. getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times) of isFullFrame(). telemetry smoothness canvas_tough_test didn't show obvious improvement or regression. BUG=411166 R=junov@chromium.org, tomhudson@google.com, reed@google.com Author: yunchao.he@intel.com Review URL: https://codereview.chromium.org/545813002
* Let SkTaskGroup work synchronously if no one created an SkTaskGroup::Enabler.Gravatar mtklein2014-09-12
| | | | | | | | | | | Tested by running DM with its SkTaskGroup::Enabler commented out. Slow, but completed correctly. BUG=skia: R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/556223003
* SkData can allocate room for its contents in the same blockGravatar reed2014-09-11
| | | | | | | | | BUG=skia: R=bungeman@google.com, mtklein@google.com Author: reed@google.com Review URL: https://codereview.chromium.org/560653004
* Detect presence of dwrite_1.h.Gravatar bungeman2014-09-10
| | | | | | | | | | | | | | | | | | This introduces the SK_HAS_DWRITE_1_H define which may be set at build time or will be true when WINVER_MAXVER >= 0x0602 . The dwrite_1.h header is available starting in Windows SDK 8.0. This change supports users who must still use Windows SDK 7.0. It also allows for easier local testing of the older interfaces on newer versions of Windows. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1053652 R=george@mozilla.com, mtklein@google.com Author: bungeman@google.com Review URL: https://codereview.chromium.org/552383002
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-22 03:39:25 +0000