aboutsummaryrefslogtreecommitdiffhomepage
path: root/include
Commit message (Collapse)AuthorAge
* Skip temp texture when config conversion test has already failed.Gravatar bsalomon2015-07-29
| | | | Review URL: https://codereview.chromium.org/1261033005
* Revert "Move the rest of src headers used by include to include/private."Gravatar Mike Klein2015-07-28
| | | | | | | | | | | | This reverts commit d12e6ffa5cc1c1af47bf73c7c127d8d7f7443058. Our Chrome roll canaries are failing with the dreaded Ninja-says-there's-more-work-to-do message. I will break this up smaller (if possible) and try again tomorrow. BUG=skia:4126 Review URL: https://codereview.chromium.org/1258293004 .
* Move the rest of src headers used by include to include/private.Gravatar mtklein2015-07-28
| | | | | | | | | | | | | $ git grep "../../src/" | grep include now returns nothing. BUG=skia:4126 No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1261013003
* Removed GrFragmentProcessor::fWillUseInputColorGravatar wangyix2015-07-28
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1259303003
* Move SkTHash.h to include/private.Gravatar mtklein2015-07-28
| | | | | | | | | | | | | | | include/views/SkOSWindow_Win.h includes it. To move SkTHash.h to include/private, SkChecksum.h needs to go there too. To move SkChecksum.h to include/private, SkTLogic needs to go there too. This adds a bunch of -Iinclude/private to tools.gyp I missed in the last CL. No public API changes. TBR=reed@google.com BUG=skia:4126 Review URL: https://codereview.chromium.org/1260613006
* remove all guards for changes to drawBitmapRect / drawImageRectGravatar reed2015-07-28
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1239193002
* change getBounds to return 0000 iff there are zero pointsGravatar reed2015-07-28
| | | | | | | | | | This is a contract change for SkPath::getBounds(), which formally was defined to return 0,0,0,0 for a 1-point path, regardless of the coordinates of that point. This seems wacky/inconsistent, and was causing other bugs (incorrect bounds) when this was unioned with other rects. Does anyone remember why we defined it this way? BUG=513799 Review URL: https://codereview.chromium.org/1261773002
* No one calls SkXfermode::GetProc16Gravatar mtklein2015-07-27
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1253493002
* Remove sk_memcpy32Gravatar mtklein2015-07-27
| | | | | | | | | | | | | | | | | | | | | | | | It's only implemented on x86, where the exisiting benchmark says memcpy() is faster for all cases: Timer overhead: 24ns curr/maxrss loops min median mean max stddev samples config bench 10/10 MB 1 35.9µs 36.2µs 36.2µs 36.6µs 1% ▁▂▄▅▅▃█▄▄▅ nonrendering sk_memcpy32_100000 10/10 MB 13 2.27µs 2.28µs 2.28µs 2.29µs 0% █▄▃▅▃▁▃▅▁▄ nonrendering sk_memcpy32_10000 11/11 MB 677 91.6ns 95.9ns 94.5ns 99.4ns 3% ▅▅▅▅▅█▁▁▁▁ nonrendering sk_memcpy32_1000 11/11 MB 1171 20ns 20.9ns 21.3ns 23.4ns 6% ▁▁▇▃▃▃█▇▃▃ nonrendering sk_memcpy32_100 11/11 MB 1952 14ns 14ns 14.3ns 15.2ns 3% ▁▁██▁▁▁▁▁▁ nonrendering sk_memcpy32_10 11/11 MB 5 33.6µs 33.7µs 34.1µs 35.2µs 2% ▆▇█▁▁▁▁▁▁▁ nonrendering memcpy32_memcpy_100000 11/11 MB 18 2.12µs 2.22µs 2.24µs 2.39µs 5% ▂█▄▇█▄▇▁▁▁ nonrendering memcpy32_memcpy_10000 11/11 MB 1112 87.3ns 87.3ns 89.1ns 93.7ns 3% ▄██▄▁▁▁▁▁▁ nonrendering memcpy32_memcpy_1000 11/11 MB 2124 12.8ns 13.3ns 13.5ns 14.8ns 6% ▁▁▁█▃▃█▇▃▃ nonrendering memcpy32_memcpy_100 11/11 MB 3077 9ns 9.41ns 9.52ns 10.2ns 4% ▃█▁█▃▃▃▃▃▃ nonrendering memcpy32_memcpy_10 (Why? One fewer thing to port to SkOpts.) BUG=skia:4117 Review URL: https://codereview.chromium.org/1256763003
* Make peekPixels() usable with raster surface snapshotsGravatar fmalita2015-07-27
| | | | | | | | | | | | | | | SkSurface_Raster snapshots do not lock their backing bitmaps when the pixel ref is shared - they only lock on deep-copy. But since for raster surfaces the pixels are always in memory, I think it would be OK to also lock in the former case. This allows for optimized (zero-copy) reads of raster surface snapshot data. R=reed@google.com Review URL: https://codereview.chromium.org/1256993002
* Remove test of illegal behavior that modifies a texture backing an SkImage.Gravatar bsalomon2015-07-23
| | | | Review URL: https://codereview.chromium.org/1244143004
* Update fallback rsqrt implementation to use optimal constants.Gravatar jvanverth2015-07-23
| | | | | | | | | Improves max relative error from 0.00175126 to 0.000650197. Also add unit tests to check error bounds. BUG=chromium:511458 Review URL: https://codereview.chromium.org/1251423002
* Have Windows use _mm_rsqrt_ss too.Gravatar mtklein2015-07-23
| | | | | | | | | | | | | | | | | | | | | | | Tidy up a little while I'm in here: 1) SIMD headers are now included by SkTypes.h as appropriate. 2) _mm_cvtss_f32() is pithier and generates the same code. Looks like this is the only code checking for SSE wrong. After this CL: ~/skia (sse) $ git grep __SSE include/core/SkPreConfig.h: #if defined(__SSE4_2__) include/core/SkPreConfig.h: #elif defined(__SSE4_1__) include/core/SkPreConfig.h: #elif defined(__SSE3__) include/core/SkPreConfig.h: #elif defined(__SSE2__) every other check is in SkPreConfig.h where it belongs. This is going to affect some GMs subtly on Windows. BUG=chromium:511458 No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1248503004
* Misc cleanupGravatar robertphillips2015-07-22
| | | | | | | | | | This is split off of https://codereview.chromium.org/1225923010/ (Start tightening correspondence betweeen GrDrawContext and GrRenderTarget). It: fixes some style nits replaces some passing of GrContext with GrTextureProvider & GrDrawContext does a bit of the finer grained creation of GrDrawContexts Review URL: https://codereview.chromium.org/1245183002
* Add the ability to decode a subset to SkCodecGravatar scroggo2015-07-22
| | | | | | | | | | | | | | | | | | | | | | | | This allows codecs that support subsets natively (i.e. WEBP) to do so. Add a field on SkCodec::Options representing the subset. Add a method on SkCodec to find a valid subset which approximately matches a desired subset. Implement subset decodes in SkWebpCodec. Add a test in DM for decoding subsets. Notice that we only start on even boundaries. This is due to the way libwebp's API works. SkWEBPImageDecoder does not take this into account, which results in visual artifacts. FIXME: Subsets with scaling are not pixel identical, but close. (This may be fine, though - they are not perceptually different. We'll just need to mark another set of images in gold as valid, once https://skbug.com/4038 is fixed, so we can tests scaled webp without generating new images on each run.) Review URL: https://codereview.chromium.org/1240143002
* Compile with VS2015.Gravatar bungeman2015-07-21
| | | | | | | | | | | | | | | | Visual Studio 2015 has additional warnings around noexcept and disabling exceptions, which can be worked around with the (undocumented) _HAS_EXCEPTIONS macro. Visual Studio 2013 and 2015 have roundf in math.h, so use it to avoid extra work and casts. We avoid using cmath, as it undefs isfinite on gcc, but Visual Studio 2015 no longer provides overloads of copysign from math.h (which is actually correct). As a result, use copysignf (which is available in math.h in 2013 and 2015) directly. Review URL: https://codereview.chromium.org/1244173005
* De-templatize Sk4pxXfermode code a bit.Gravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deduplicates a few pieces of code: - we end up with one copy of each xfer32() driver loop instead of one per xfermode; - we end up with two* copies of each xfermode implementation instead of ten**. * For a given Mode: Mode() itself and xfer_aa<Mode>(). ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA. This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON. If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings. Performance is affected in proportion to the original xfermode speed: fast modes like Plus take the largest proportional hit, and slow modes like HardLight or SoftLight see essentially no hit at all. This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty. For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things. TBR=reed@google.com No public API changes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot Review URL: https://codereview.chromium.org/1242743004
* Revert of De-templatize Sk4pxXfermode code a bit. (patchset #2 id:20001 of ↵Gravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1242743004/) Reason for revert: http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon/builds/1168/steps/build%20most/logs/stdio Original issue's description: > De-templatize Sk4pxXfermode code a bit. > > This deduplicates a few pieces of code: > - we end up with one copy of each xfer32() driver loop instead of one per xfermode; > - we end up with two* copies of each xfermode implementation instead of ten**. > > * For a given Mode: Mode() itself and xfer_aa<Mode>(). > ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA. > > This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON. > > If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings. > > Performance is affected in proportion to the original xfermode speed: > fast modes like Plus take the largest proportional hit, and slow modes > like HardLight or SoftLight see essentially no hit at all. > > This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty. > > For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things. > > TBR=reed@google.com > No public API changes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da TBR=msarett@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1245273005
* De-templatize Sk4pxXfermode code a bit.Gravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This deduplicates a few pieces of code: - we end up with one copy of each xfer32() driver loop instead of one per xfermode; - we end up with two* copies of each xfermode implementation instead of ten**. * For a given Mode: Mode() itself and xfer_aa<Mode>(). ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA. This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON. If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings. Performance is affected in proportion to the original xfermode speed: fast modes like Plus take the largest proportional hit, and slow modes like HardLight or SoftLight see essentially no hit at all. This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty. For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things. TBR=reed@google.com No public API changes. BUG=skia: Review URL: https://codereview.chromium.org/1242743004
* Remove SK_LEGACY_IMAGE_FILTER_CROP_RECT_EDGES code.Gravatar senorblanco2015-07-21
| | | | | | | | This is no longer used in Chrome. BUG=skia:4089 Review URL: https://codereview.chromium.org/1245193002
* Add Rec709 YUV color space support to GrYUVtoRGBEffect.Gravatar rileya2015-07-20
| | | | | | | | | | | This change is motivated by a recent switch in how chromium handles <video> color spaces, making rec709 more commonly used. This will allow video -> canvas copies to take the fast GPU path when we're using 709, just as we do with 601 and jpeg. Chromium-side change: https://codereview.chromium.org/1236313002 Review URL: https://codereview.chromium.org/1241723005
* Revert[2] of guard to remove DrawBitmapRectFlagsGravatar reed2015-07-17
| | | | | | | | | This reverts commit 91110195a2eee170c11885da9d16f94b00a39f87. BUG=skia: TBR= Review URL: https://codereview.chromium.org/1240753003
* Revert of guard to remove DrawBitmapRectFlags (patchset #1 id:1 of ↵Gravatar scroggo2015-07-17
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1235393003/) Reason for revert: breaking android framework build Original issue's description: > guard to remove DrawBitmapRectFlags > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/6fb0b6779e40ce05c20cf279f0ecff31fa3cd60d TBR=fmalita@chromium.org,djsollen@google.com,reed@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1230823007
* Now that the SkImageFilter::CropRect crop edges refer toGravatar senorblanco2015-07-16
| | | | | | | | width & height, name them appropriately. BUG=240827 Review URL: https://codereview.chromium.org/1234873005
* refactor code to apply the croprectGravatar reed2015-07-16
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1218993002
* Make readpixels work on GrTexturesGravatar bsalomon2015-07-16
| | | | Review URL: https://codereview.chromium.org/1234313002
* have canvas send discard instead of retain if the draw would overwrite ↵Gravatar reed2015-07-16
| | | | | | | | | | | | everything Motivation: - perf win for clients that overwrite the surface after a snapshot. - may allow us to eliminate SkDeferredCanvas, as this was its primary advantage. BUG=skia: Review URL: https://codereview.chromium.org/1236023004
* Replace buggy_blend_modes GM with an exhaustive test.Gravatar mtklein2015-07-16
| | | | | | | | | | | | | | The new test is disabled by default, as it's quite slow. We can run it if we suspect problems by passing -x to DM. This test would have been failing before the bug fix, and now is passing. Assuming the Priv on the end means it's not considered public API... TBR=reed@google.com BUG=skia:4052 Review URL: https://codereview.chromium.org/1228333003
* guard to remove DrawBitmapRectFlagsGravatar reed2015-07-16
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1235393003
* Very tiny paths are subsumed by the ConvexicatorGravatar caryclark2015-07-14
| | | | | | | | | | | | | | | and are treated as convex when they are not. Allow the SkPath::Iter to leave degenerate path segments unmolested by passing an additional exact bool to next(). Treat any non-zero length as significant in addPt(). R=reed@google.com,robertphillips@google.com BUG=493450 Review URL: https://codereview.chromium.org/1228383002
* Another trivial cleanupGravatar joshualitt2015-07-14
| | | | | | | | | TBR=bsalomon@google.com BUG=skia: Committed: https://skia.googlesource.com/skia/+/52e7657cd850f95e66eb23c6d138ee45149a1039 Review URL: https://codereview.chromium.org/1229303003
* Implement support for CHROMIUM_path_rendering pseudo extensionGravatar kkinnunen2015-07-14
| | | | | | | | | | | | | | | | Implement support for path rendering in Chromium through CHROMIUM_path_rendering pseudo extension. The extension defines a new pseudo-gl function, BindFragmentInputLocation. This behaves similarly to the BindUniformLocation pseudo-gl function. The idea is to assign fragment input location to a fragment input before linking the program. BUG=chromium:344330 Committed: https://skia.googlesource.com/skia/+/eeef46d181f9f8db388ecea81df699fc1b3c9280 Review URL: https://codereview.chromium.org/1192663002
* add src-rect-constraint to drawImageRectGravatar reed2015-07-14
| | | | | | | | | | | Follow-on work - unify around SrcRectConstraint (i.e. drawBitmapRect) - remove silly drawBitmapRectToRect alias - clean-up (possibly remove) alias problems around drawBitmapRect + IRect parameter BUG=skia: Review URL: https://codereview.chromium.org/1228083004
* Revert of Another trivial cleanup (patchset #6 id:100001 of ↵Gravatar joshualitt2015-07-13
| | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1229303003/) Reason for revert: breaking things Original issue's description: > Another trivial cleanup > > TBR=bsalomon@google.com > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/52e7657cd850f95e66eb23c6d138ee45149a1039 TBR=robertphillips@google.com,joshualitt@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1233853004
* Add new SkPoint3 classGravatar robertphillips2015-07-13
| | | | | | The existing Light filter and the upcoming Lighting Shader both need a Point3 class Review URL: https://codereview.chromium.org/1229693009
* Another trivial cleanupGravatar joshualitt2015-07-13
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1229303003
* Modify GrClipMaskManager to reflect logical constnessGravatar joshualitt2015-07-13
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1230023003
* Fix up -Winconsistent-missing-overrideGravatar mtklein2015-07-13
| | | | | | | | | | | | | | (and a couple presubmit fixes) This allows us to turn back on -Werror for LLVM coverage builds, and more generally supports building with Clang 3.7. No public API changes. TBR=reed@google.com BUG=skia: Review URL: https://codereview.chromium.org/1232463006
* Allow creating multiple scanline decoders.Gravatar scroggo2015-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make getScanlineDecoder return a new object each time, which is owned by the caller, and independent from any existing scanline decoders and the SkCodec itself. Since the SkCodec already contains the entire state machine, and it is used by the scanline decoders, simply create a new SkCodec which is now owned by the scanline decoder. Move code that cleans up after using a scanline decoder into its destructor One side effect is that creating the first scanline decoder requires a duplication of the stream and re-reading the header. (With some more complexity/changes, we could pass the state machine to the scanline decoder and make the SkCodec recreate its own state machine instead.) The typical client of the scanline decoder (region decoder) uses an SkMemoryStream, so the duplication is cheap, although we should consider the extra time to reread the header/recreate the state machine. (If/when we use the scanline decoder for other purposes, where the stream may not be cheaply duplicated, we should consider passing the state machine.) One (intended) result of this change is that a client can create a new scanline decoder in a new thread, and decode different pieces of the image simultaneously. In SkPngCodec::decodePalette, use fBitDepth rather than a parameter. Review URL: https://codereview.chromium.org/1230033004
* Fix componene debug build failure in chromiumGravatar dongseong.hwang2015-07-10
| | | | | | | | | | | | The error log is as follows: ../../third_party/skia/include/core/SkSpinlock.h:24: error: undefined reference to 'SkPODSpinlock::contendedAcquire()' collect2: error: ld returned 1 exit status [mtklein added below here] Despite the presence in include/ and the added SK_API, this file is not part of Skia's public API... it's just used by files which are. TBR=reed@google.com Review URL: https://codereview.chromium.org/1229003004
* Move GrProcessorDataManager to GrMemoryPoolGravatar joshualitt2015-07-10
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1225363002
* remove getter for imagegenerator factory, update testGravatar reed2015-07-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1223413002
* Create a template AutoTAcquire, and specialize an SkMutex version.Gravatar herb2015-07-09
| | | | | | | | Add copyright notice. BUG=skia: Review URL: https://codereview.chromium.org/1230583008
* Remove setFromPaint from GrPipelineBuilderGravatar joshualitt2015-07-09
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1227153003
* add runtime option to provide data->imagegenerator factoryGravatar reed2015-07-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1229933003
* Outline SkSpinlock::acquire().Gravatar mtklein2015-07-09
| | | | | | | | | | | | | | | | The proportion of time spent doing useful work is well over 99% in acquire(), so outlining it doesn't hurt speed at all, and makes it much easier to pick out on a profile. It'd be about 50/50 work/overhead if we outlined the extremely-cheap release(). I also tried outlining some SkRefCnt methods with similar mixed results. BUG=skia: No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1212253013
* More threading of GrProcessorDataManagerGravatar joshualitt2015-07-09
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1230813003
* Remove SkImageGenerator pieces only for SkCodec.Gravatar scroggo2015-07-09
| | | | | | | | | | | Follow up to the split between SkImageGenerator and SkCodec. Now that SkCodec does not inherit from SkImageGenerator, SkImageGenerator no longer needs Options or Result, which were added for SkCodec. Remove them, but keep them behind a flag, since Chromium has its own subclasses of SkImageGenerator which assume the old signature for onGetPixels. Review URL: https://codereview.chromium.org/1226023003
* SkCodec no longer inherits from SkImageGenerator.Gravatar scroggo2015-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkImageGenerator makes some assumptions that are not necessarily valid for SkCodec. For example, SkCodec does not assume that it can always be rewound. We also have an ongoing question of what an SkCodec should report as its default settings (i.e. the return from getInfo). It makes sense for an SkCodec to report that its pixels are unpremultiplied, if that is the case for the underlying data, but if a client of SkImageGenerator uses the default settings (as many do), they will receive unpremultiplied pixels which cannot (currently) be drawn with Skia. We may ultimately decide to revisit SkCodec reporting an SkImageInfo, but I have left it unchanged for now. Import features of SkImageGenerator used by SkCodec into SkCodec. I have left SkImageGenerator unchanged for now, but it no longer needs Result or Options. This will require changes to Chromium. Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h can include SkCodec.h (where Result is), and SkCodec.h does not need to include it (to delete fScanlineDecoder). In many places, make the following simple changes: - Now include SkScanlineDecoder.h, which is no longer included by SkCodec.h - Use the enums in SkCodec, rather than SkImageGenerator - Stop including SkImageGenerator.h where no longer needed Review URL: https://codereview.chromium.org/1220733013
* rename GrShaderDataManager -> GrProcessorDataManagerGravatar joshualitt2015-07-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1228683002
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-02 01:59:24 +0000