aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/utils
Commit message (Collapse)AuthorAge
* 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
* Hide fields in SkImageInfoGravatar reed2014-09-03
| | | | | | | | | R=rmistry@google.com TBR=bsalomon Author: reed@google.com Review URL: https://codereview.chromium.org/536003002
* make allocPixels throw on failureGravatar reed2014-09-02
| | | | | | | | | BUG=skia: R=mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: reed@google.com Review URL: https://codereview.chromium.org/510423005
* Debugger render support for SkDrawTextBlobCommand.Gravatar fmalita2014-08-29
| | | | | | | | R=robertphillips@google.com Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/523833003
* Try out scalar picture sizesGravatar robertphillips2014-08-29
| | | | | | | | | | This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect. R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: robertphillips@google.com Review URL: https://codereview.chromium.org/513983002
* Add missing text blob SkDrawCommand string.Gravatar fmalita2014-08-27
| | | | | | | | R=robertphillips@google.com Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/510853002
* SkTextBlob plumbingGravatar fmalita2014-08-26
| | | | | | | | | | | Add SkTextBlob serialization + drawTextBlob() overrides. R=mtklein@google.com, reed@google.com, robertphillips@google.com BUG=269080 Author: fmalita@chromium.org Review URL: https://codereview.chromium.org/499413002
* Require length in sk_wchar_to_string.Gravatar bungeman2014-08-25
| | | | | | | | | | | | | This information is already available at all call sites and allows the call to WideCharToMultiByte to not overwrite the '\0' in the writable_str() which isn't really writable. BUG=skia:1989 R=reed@google.com Author: bungeman@google.com Review URL: https://codereview.chromium.org/500113002
* remove code for (dead) SK_SUPPORT_LEGACY_GETCLIPTYPEGravatar reed2014-08-21
| | | | | | | | | BUG=skia: R=djsollen@google.com Author: reed@google.com Review URL: https://codereview.chromium.org/489103003
* Fix typoGravatar krajcevski2014-08-18
| | | | | | | | R=robertphillips@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/478533002
* Added bench for grid of patches.Gravatar dandov2014-08-15
| | | | | | | | | | | | It is on top of my previous cl to fix the mem leaks of the regular patch bench. NOTREECHECKS=true BUG=skia: R=egdaniel@google.com, bsalomon@google.com Author: dandov@google.com Review URL: https://codereview.chromium.org/470543004
* Fixed memory leak for nanobench and crashing in SampleAppGravatar dandov2014-08-15
| | | | | | | | | | | NOTREECHECKS=True BUG=skia:2830 R=mtklein@google.com, egdaniel@google.com Author: dandov@google.com Review URL: https://codereview.chromium.org/469333002
* Add support for new drawPicture entry point to debuggerGravatar robertphillips2014-08-13
| | | | | | | | R=fmalita@google.com, fmalita@chromium.org Author: robertphillips@google.com Review URL: https://codereview.chromium.org/464063003
* Proposal for the mesh gradient interface. Implemented as a grid ofGravatar dandov2014-08-12
| | | | | | | | | | | | | | | | patches and uses 4 private arrays to store the values of the control points and colors. When it needs a patch at a certain position of the grid it just builds it using the corresponding values of the array and the grid coordinates provided. Details on implementation are documented in the corresponding classes' comments. Also added a gm for mesh gradients. BUG=skia: R=egdaniel@google.com, reed@google.com Author: dandov@google.com Review URL: https://codereview.chromium.org/451723003
* Turn off pedantic blit rectGravatar krajcevski2014-08-12
| | | | | | | | R=robertphillips@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/460253003
* Replace LLU with ULL to make VS2012 work again.Gravatar halcanary2014-08-12
| | | | | | | | R=bungeman@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/458663004
* Migrate SkRTConfRegistry test to DEF_TEST().Gravatar tfarina2014-08-12
| | | | | | | | | | BUG=None TEST=dm --tests=true --gms=false R=mtklein@google.com, bsalomon@google.com Author: tfarina@chromium.org Review URL: https://codereview.chromium.org/444303002
* SkCanvas::drawPatch param SkPoint[12]Gravatar dandov2014-08-12
| | | | | | | | | | | | | | | | | | drawPatch now receives as parameter const SkPoint cubics[12] Adjusted derived classes and serialization. Ajusted GM's and benches that take into account combinations of optional parameters, the scale of the patch and 4 different types of patches. Planning on adding the extra functionality of SkPatch in another CL. BUG=skia: R=egdaniel@google.com, reed@google.com Author: dandov@google.com Review URL: https://codereview.chromium.org/463493002
* Add BlitRect to SkTCompressedAlphaBlitterGravatar krajcevski2014-08-11
| | | | | | | | R=robertphillips@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/456873003
* add drawPicture variant that takes a matrix and paintGravatar reed2014-08-09
| | | | | | | | | | will need some staging strategy, since chrome and blink have overrides of onDrawPicture R=robertphillips@google.com, fmalita@google.com, bsalomon@google.com, mtklein@google.com Author: reed@google.com Review URL: https://codereview.chromium.org/448793004
* Implement BlitRect for SkTCompressedAlphaBlitterGravatar krajcevski2014-08-08
| | | | | | | | R=robertphillips@google.com, reed@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/451823002
* Fix bug in blitAntiHGravatar krajcevski2014-08-08
| | | | | | | | R=robertphillips@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/449223002
* Add option to dump images from nanobench.Gravatar bsalomon2014-08-07
| | | | | | | | | | Add option to set the repeat count to any number, replacs the --runOnce flag. R=mtklein@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/450743002
* Add astcbitmap to gm slides.Gravatar krajcevski2014-08-07
| | | | | | | | | | | Add additional ASTC formats. Add astc image decoder files. R=reed@google.com, robertphillips@google.com, halcanary@google.com Author: krajcevski@google.com Review URL: https://codereview.chromium.org/444093002
* Revert of - Add astcbitmap to gm slides ↵Gravatar krajcevski2014-08-07
| | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/444093002/) Reason for revert: Breaking DM Original issue's description: > - Add astcbitmap to gm slides > - Add additional ASTC formats > - Add astc image decoder files > > Committed: https://skia.googlesource.com/skia/+/2fc05823fed4b9649338f3029cd1ba05ef49a02f R=reed@google.com, robertphillips@google.com, halcanary@google.com TBR=halcanary@google.com, reed@google.com, robertphillips@google.com NOTREECHECKS=true NOTRY=true Author: krajcevski@google.com Review URL: https://codereview.chromium.org/447343002
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 03:28:06 +0000