aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* Add skia_use_android_framework_defines GYP_DEFINEGravatar borenet2015-07-22
| | | | | | BUG=skia:4082 Review URL: https://codereview.chromium.org/1243383002
* 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
* Update Android Apps to use gradleGravatar djsollen2015-07-22
| | | | | | | | | This CL replaces ant with gradle for the task of building APKs. The primary driver of this change is that it now allow us to develop and test our apps using Android Studio. DOCS_PREVIEW= https://skia.org/?cl=1215023017 Review URL: https://codereview.chromium.org/1215023017
* Fix up textblobcachetestGravatar joshualitt2015-07-22
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1250003003
* 565 support for SIMD xfermodesGravatar mtklein2015-07-22
| | | | | | | | | | | | | | | | | | | | | | This uses the most basic approach possible: - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors. - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially. Clearly, we can optimize these loads and stores. That's a TODO. The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling. The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster. This will cause minor GM diffs, but I don't think any layout test changes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0 Committed: https://skia.googlesource.com/skia/+/860dcaa2ddfdadc050af4f943a84a9d499315066 Review URL: https://codereview.chromium.org/1245673002
* Add drawImage{Rect,} support to SkDebugCanvasGravatar fmalita2015-07-22
| | | | | | R=robertphillips@google.com,mtklein@google.com Review URL: https://codereview.chromium.org/1253473002
* Moved GrGLFragmentProcessor definition to its own fileGravatar wangyix2015-07-22
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1246193002
* Remove some redundant fields from BitmapTextBatch (and rename to TextBatch).Gravatar bsalomon2015-07-22
| | | | Review URL: https://codereview.chromium.org/1244093004
* skia: GrGLAssembleGLInterface update load chromium extension functionsGravatar hendrikw2015-07-22
| | | | | | | | Command buffer will expose GL_CHROMIUM_framebuffer_multisample and GL_CHROMIUM_map_sub, added support for these to enable interface validation to succeed. Review URL: https://codereview.chromium.org/1248853003
* Fix Android framework buildGravatar msarett2015-07-22
| | | | | | | | | | | | The Android framework was failing on conditions in libjpeg-turbo.gyp, even though libjpeg-turbo is listed in dependencies! for the framework (maybe because I forgot to add export_dependent_settings!). This is fixed by rearranging the gyp file. BUG=skia: Review URL: https://codereview.chromium.org/1249003002
* Fix tile drop-out on S4 for texture decal mode.Gravatar jvanverth2015-07-22
| | | | | | | | | Switch to use highp on interpolants. Also removes some unnecessary formatting. BUG=skia:3381 Review URL: https://codereview.chromium.org/1245703004
* Coverage: add a trace for not_covered_lines per fileGravatar borenet2015-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example output: { "build_number": "2", "gitHash": "71f5db892ee7ed9fbb573da28ccb906e18ba24a4", "key": { "arch": "x86_64", "compiler": "Clang", "configuration": "Coverage", "cpu_or_gpu": "CPU", "cpu_or_gpu_value": "AVX2", "model": "GCE", "os": "Ubuntu" }, "results": { "dm_DMGpuSupport_h": { "coverage": { "lines_not_covered": 6, "options": { "dir": "dm", "fullname": "dm/DMGpuSupport.h", "source_type": "coverage" }, "percent": 33.33333333333333 } }, "dm_DMJsonWriter_cpp": { ...... BUG=skia:2430 Review URL: https://codereview.chromium.org/1246043002
* 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
* Fix SkCanvas::wouldOverwriteEntireSurface() contains testGravatar fmalita2015-07-22
| | | | | | R=reed@google.com,robertphillips@google.com,bsalomon@google.com Review URL: https://codereview.chromium.org/1244093005
* Fix CQ keyword and add more detailGravatar rmistry2015-07-22
| | | | | | | | | BUG=skia: NOTRY=true DOCS_PREVIEW= https://skia.org/?cl=1246393002 TBR=jcgregorio Review URL: https://codereview.chromium.org/1246393002
* Revert of 565 support for SIMD xfermodes (patchset #4 id:60001 of ↵Gravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1245673002/) Reason for revert: NEON 565 gold images have gone ugly. This is what I get for writing and testing SSE and just writing NEON. E.g. colortype_xfermodes, dstreadshuffle, bigbitmaprect, pictures, textbloblooper, aaxfermodes (only Plus) Original issue's description: > 565 support for SIMD xfermodes > > This uses the most basic approach possible: > - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors. > - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially. > > Clearly, we can optimize these loads and stores. That's a TODO. > > The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling. > > The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster. > > This will cause minor GM diffs, but I don't think any layout test changes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0 > > Committed: https://skia.googlesource.com/skia/+/860dcaa2ddfdadc050af4f943a84a9d499315066 TBR=msarett@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1248893004
* 565 support for SIMD xfermodesGravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | This uses the most basic approach possible: - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors. - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially. Clearly, we can optimize these loads and stores. That's a TODO. The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling. The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster. This will cause minor GM diffs, but I don't think any layout test changes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0 Review URL: https://codereview.chromium.org/1245673002
* Change the GlyphCache to use a hash table instead of doing its own ad-hocGravatar herb2015-07-21
| | | | | | | hashing. This change appears to be performance neutral. BUG=skia: Review URL: https://codereview.chromium.org/1216983003
* ANGLE deps rollGravatar hendrikw2015-07-21
| | | | | | | | | | | | | | | If we ever want to allow the command buffer as a skia gles2 backend, we need a more up to date version of ANGLE, specifically there are 4 defines that differ between newer and older versions of ANGLE which we use in skia, I've updated these in this change. I'm not quite sure if what I've done for the 'angle_path' is correct, I tried setting it to a path relative to skia, and to '<(DEPTH)', both of which do not compile correctly, only '../' worked. Committed: https://skia.googlesource.com/skia/+/db0b1e796ddbd08e6be8a666537318b1c0e2ce56 Review URL: https://codereview.chromium.org/1244843003
* 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
* Revert of Bilinear optimization for 1D convolution. (patchset #5 id:200001 ↵Gravatar ericrk2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | of https://codereview.chromium.org/1216623003/) Reason for revert: Ok, I am now seeing a couple issues. going to revert and investigate further. Original issue's description: > Bilinear optimization for 1D convolution. > > Splits GrGLConvolutionEffect into GrGLBilerpConvolutionEffect and > GrGLBoundedConvolutionEffect. When doing a non-bounded convolution we now > always use the GrGLBilerpConvolutionEffect which uses bilinear filtering to > perform half as many samples in the texture. > > BUG=skia:3986 > > Committed: https://skia.googlesource.com/skia/+/91abe10af417148939548551e210c001022d3bda > > Committed: https://skia.googlesource.com/skia/+/0f38612b0facf585854aba4556433b858cbf7da8 TBR=bsalomon@google.com,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:3986 Review URL: https://codereview.chromium.org/1247063005
* Revert of skia: ANGLE deps roll (patchset #1 id:1 of ↵Gravatar hendrikw2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1244843003/) Reason for revert: Compile error that the try bots didn't catch :( Original issue's description: > ANGLE deps roll > > If we ever want to allow the command buffer as a skia gles2 backend, > we need a more up to date version of ANGLE, specifically there are > 4 defines that differ between newer and older versions of ANGLE which > we use in skia, I've updated these in this change. > > I'm not quite sure if what I've done for the 'angle_path' is correct, > I tried setting it to a path relative to skia, and to '<(DEPTH)', both > of which do not compile correctly, only '../' worked. > > Committed: https://skia.googlesource.com/skia/+/db0b1e796ddbd08e6be8a666537318b1c0e2ce56 TBR=bsalomon@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1245223007
* ANGLE deps rollGravatar hendrikw2015-07-21
| | | | | | | | | | | | | If we ever want to allow the command buffer as a skia gles2 backend, we need a more up to date version of ANGLE, specifically there are 4 defines that differ between newer and older versions of ANGLE which we use in skia, I've updated these in this change. I'm not quite sure if what I've done for the 'angle_path' is correct, I tried setting it to a path relative to skia, and to '<(DEPTH)', both of which do not compile correctly, only '../' worked. Review URL: https://codereview.chromium.org/1244843003
* Bilinear optimization for 1D convolution.Gravatar ericrk2015-07-21
| | | | | | | | | | | | | Splits GrGLConvolutionEffect into GrGLBilerpConvolutionEffect and GrGLBoundedConvolutionEffect. When doing a non-bounded convolution we now always use the GrGLBilerpConvolutionEffect which uses bilinear filtering to perform half as many samples in the texture. BUG=skia:3986 Committed: https://skia.googlesource.com/skia/+/91abe10af417148939548551e210c001022d3bda Review URL: https://codereview.chromium.org/1216623003
* make mixedtextblobs gm portableGravatar caryclark2015-07-21
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1250753004
* Clean up more SkXfermode.cpp dead code.Gravatar mtklein2015-07-21
| | | | | | | | | | | | | These handwritten xfermodes for Clear, Src, DstIn, and DstOut are actually dead code: they're all covered by Sk4pxXfermode, which we'd already have returned. Tidies up the xfermode creation logic to make this clearer. This cuts 20-40K off SkXfermode.o, depending on the platform. BUG=skia: Review URL: https://codereview.chromium.org/1249773004
* adding assert to GrAtlasTextContextGravatar joshualitt2015-07-21
| | | | | | | TBR=bsalomon@google.com BUG=skia: Review URL: https://codereview.chromium.org/1241263003
* 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
* make color emoji gm portableGravatar caryclark2015-07-21
| | | | | | R=bungeman@google.com Review URL: https://codereview.chromium.org/1248703004
* 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
* Possible fix Moto E compilation failureGravatar robertphillips2015-07-21
| | | | | | | | It appears that the Adreno compiler is even more twitchy about gl_FragCoord handling than expected. BUG=skia:4078 Review URL: https://codereview.chromium.org/1246773003
* 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
* Reenable yasm for Android x86 and x86-64 on Linux hostGravatar msarett2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that gyp (kind of) has support for cross compiling with a different host and target. We simply need to specify CC_host and CC_target instead of CC. Making this change allows us to compile yasm on a Linux host for Android. We run into problems on Mac because the linker on a Mac host requires different command line arguments than the linker on the Android target. In looking through the code for gyp itself and speaking to Ben, it doesn't appear to me that gyp supports passing different arguments to host and target linkers. I would imagine that we would have similar problems on Windows. Below is a link to a CL that would fix this issue in gyp. It looks like it has been dropped for a long time. Thanks to Ben for this link! https://chromiumcodereview.appspot.com/10795044/ Also I'm adding a link to the build instructions for Chrome (thanks again Ben). It looks like they only support building for Android from Linux. https://code.google.com/p/chromium/wiki/AndroidBuildInstructions My next steps are: 1) Getting in touch with Torne or someone else with gyp to see if people are aware of this issue or interested in fixing it. 2) Deciding if skia should care about this issue. 3) Deciding if skia should work around this issue. It'd be really great to hear your thoughts on (2) and (3). My first thought is that we shouldn't care because, as long as we always compile the production copy of skia for Android on Linux, we will get the fast code. Is this a valid conclusion? Is there a way to write Android apps on Mac that accidentally use the slower code? If we do care, there are workarounds: For Mac, we can check in a yasm binary - it's a little smaller than the one I am deleting in this CL :-/ For Windows, we *might* be able to use the yasm.exe binary already in externals (we get this from DEPS because this is how chromium uses yasm on Windows). Are there other platforms that we care about? Let me know what you think! BUG=skia:4028 DOCS_PREVIEW= https://skia.org/?cl=1239333002 Review URL: https://codereview.chromium.org/1239333002
* Add sanity check to GrAtlasTextBlobGravatar joshualitt2015-07-21
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1250693002
* 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
* make varied_text* gm portableGravatar caryclark2015-07-21
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1244063002
* Run noise shader separately in imagefiltersclippedGravatar jvanverth2015-07-21
| | | | | | BUG=skia:4079 Review URL: https://codereview.chromium.org/1245983002
* rename BitmapTextBlob and move it to its own fileGravatar joshualitt2015-07-21
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1249663002
* make xfermode* portableGravatar caryclark2015-07-21
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1243103002
* Skip imagefiltersclipped GM on Galaxy S4Gravatar borenet2015-07-21
| | | | | | BUG=skia:4079 Review URL: https://codereview.chromium.org/1250473005
* Revert of 565 support for SIMD xfermodes (patchset #3 id:40001 of ↵Gravatar mtklein2015-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1245673002/) Reason for revert: 942930d (included in this roll) introduced a 140 kB sizes regression in libskia.so. Please investigate and reland if this regression is necessary. Original issue's description: > 565 support for SIMD xfermodes > > This uses the most basic approach possible: > - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors. > - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially. > > Clearly, we can optimize these loads and stores. That's a TODO. > > The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling. > > The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster. > > This will cause minor GM diffs, but I don't think any layout test changes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0 TBR=msarett@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1242973004
* 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
* Generate platform specific fontmgr gm.Gravatar caryclark2015-07-20
| | | | | | | | | | | | | | | The gm output on different font platforms is so different that comparing images in Gold has little value. Separate the images by appending platform information to the gm name to group somewhat similar images together. Note that this does not attempt to make sure that all images generated by Gold are nearly pixel identical; it only reduces the number of nonsensical comparisons. R=bungeman@google.com Review URL: https://codereview.chromium.org/1245643002
* removing png_read_end from SkPngScanlineDecoderGravatar emmaleer2015-07-20
| | | | | | BUG=skia:4041 Review URL: https://codereview.chromium.org/1242423002
* make stroketext textblob* texteffects tileimagefilter gm portableGravatar caryclark2015-07-20
| | | | | | TBR=reed@google.com Review URL: https://codereview.chromium.org/1244833002
* 565 support for SIMD xfermodesGravatar mtklein2015-07-20
| | | | | | | | | | | | | | | | | | This uses the most basic approach possible: - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors. - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially. Clearly, we can optimize these loads and stores. That's a TODO. The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling. The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster. This will cause minor GM diffs, but I don't think any layout test changes. BUG=skia: Review URL: https://codereview.chromium.org/1245673002
* Fix textureDomain/bleed prevention in msaaGravatar robertphillips2015-07-20
| | | | | | | | | | This updates Ganesh's bleed avoidance check to handle the case where the sample location may be outside of the rect geometry but used because it partially covers the pixel. BUG=skia:4066 Review URL: https://codereview.chromium.org/1237623012
* Split llvm_coverage_run into two scriptsGravatar borenet2015-07-20
| | | | | | | | | ... One for running to generate the coverage data, another to parse the data into various formats. NOTRY=true BUG=skia:2430 Review URL: https://codereview.chromium.org/1239963002
* Clean up dead xfermode opts code.Gravatar mtklein2015-07-20
| | | | | | | | | | | | | Now that SK_SUPPORT_LEGACY_XFERMODES is unused, tons of code becomes dead. Nothing is needed in opts/ anymore for x86. We still do runtime NEON detection, which just duplicates Sk4pxXfermode. TBR=reed@google.com BUG=skia: Review URL: https://codereview.chromium.org/1230023011
* Update SKP versionGravatar skia.buildbots2015-07-19
| | | | | | | | | Automatic commit by the RecreateSKPs bot. TBR= NO_MERGE_BUILDS Review URL: https://codereview.chromium.org/1241073002
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 07:07:28 +0000