aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* Enable both static and dynamically linked libpngGravatar djsollen2015-04-03
| | | | | | | | | | | All platforms except android are configured to use the statically linked copy of libpng. Android uses the system provided dynamic copy for SkImageDecoder and the static copy for SkCodec. The exception being android framework builds that currently use the dynamic copy everywhere. This CL also enables NEON optimizations for libpng. Review URL: https://codereview.chromium.org/1058823002
* enable sk4f xfermodesGravatar reed2015-04-03
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1061543002
* Try ARMv7 and NEON for Daisy.Gravatar mtklein2015-04-03
| | | | | | | | | | | | | I think Daisy's color order problems are in non-NEON ARM assembly. NEON might actually be fine. BUG=skia:1843 Committed: https://skia.googlesource.com/skia/+/a121c0ee6b911dd7004c6054a8692d37084b6b3d CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-CrOS_Daisy-Trybot,Build-Ubuntu-GCC-Arm7-Debug-Android_Neon-Trybot,Build-Ubuntu-GCC-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot Review URL: https://codereview.chromium.org/1054233002
* Delete no longer needed pagesets, add new pagesets and make names more readableGravatar rmistry2015-04-03
| | | | | | | | | | Deleted all pagesets mentioned in https://code.google.com/p/skia/issues/detail?id=3574#c18 Added new Wikipedia and Unicodetable pagesets from https://code.google.com/p/skia/issues/detail?id=3574#c19 BUG=skia:3574 NOTRY=true Review URL: https://codereview.chromium.org/1053253003
* BUG=skia:Gravatar joshualitt2015-04-03
| | | | Review URL: https://codereview.chromium.org/1031423002
* Doesn't usually matter for well-formed blacklists,Gravatar mtklein2015-04-03
| | | | | | | | but helps us not run off the end. BUG=skia: Review URL: https://codereview.chromium.org/1059243002
* Update DM to allow Src's to have optional options.Gravatar djsollen2015-04-03
| | | | Review URL: https://codereview.chromium.org/1059513002
* Get rid of leaks in SkCodec::NewFromStream.Gravatar scroggo2015-04-03
| | | | | | | | | | | | | | | | | | | | SkCodec::NewFromStream claims to delete the passed in SkStream on failure. This allows the caller to pass an SkStream to the function and not worry about deleting it depending on the return value. Most of our SkCodecs did not honor this contract though. Update them to delete the stream on failure. Further, update SkCodec::NewFromStream to delete the stream if it did not match any subclass, and delete the SkCodec if we decided to return NULL because it was too big. Add a test which tests streams which represent the beginnings of supported format types but do not contain enough data to create an SkCodec. The interesting part of the test is when we run it on ASAN, which will report that we leaked something without the other changes. BUG=skia:3257 Review URL: https://codereview.chromium.org/1058873006
* New names for SkPMFloat methods.Gravatar mtklein2015-04-03
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1055123002
* Prevent DM crash in the PDF sink when src width/height are zero.Gravatar djsollen2015-04-03
| | | | Review URL: https://codereview.chromium.org/1061493002
* Use switch operator[](int) to kth<int>() so we can use vget_lane.Gravatar mtklein2015-04-03
| | | | | | | | | #floats BUG=skia: BUG=skia:3592 Review URL: https://codereview.chromium.org/1059743002
* remove useless benchesGravatar reed2015-04-02
| | | | | | | | | | The colorfilter is applied to a single (paint's) color, so the bench does not measure the filter at all, but simply the blit of a color. BUG=skia: TBR= Review URL: https://codereview.chromium.org/1055383002
* Exclusion and Difference modes using Sk4fGravatar reed2015-04-02
| | | | | | | | | | | | | | Before: 7M 1 15.3ms 15.5ms 15.8ms 17.2ms 4% ▁█▄▁▇▂▁▁▂▁ 8888 Xfermode_Exclusion 7M 1 16.5ms 17.1ms 17.3ms 18.8ms 5% ▁█▃█▃▂▂▃▂▂ 8888 Xfermode_Difference After: 7M 1 9.06ms 9.34ms 9.42ms 10.4ms 4% ▁▁▅▄█▁▂▁▂▃ 8888 Xfermode_Exclusion 7M 1 10.5ms 10.9ms 11ms 12ms 5% ▃▁▆█▂▁▅▂▁▃ 8888 Xfermode_Difference TBR=mtklein@google.com Review URL: https://codereview.chromium.org/1060493002
* impl Multiply mode using Sk4fGravatar reed2015-04-02
| | | | | | | | | | | | Before: 7M 1 14.4ms 14.8ms 15.4ms 17.5ms 7% ▆█▅▅▂▁▁▁▂▁ 8888 Xfermode_Multiply After: 7M 1 12ms 12.1ms 12.5ms 14.1ms 6% ▃█▇▂▁▂▁▁▂▁ 8888 Xfermode_Multiply TBR=mtklein@google.com Review URL: https://codereview.chromium.org/1056003002
* Revert of Try ARMv7 and NEON for Daisy. (patchset #1 id:1 of ↵Gravatar mtklein2015-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1054233002/) Reason for revert: whatever compiler we're using can't handle array subscripts for neon vectors Original issue's description: > Try ARMv7 and NEON for Daisy. > > I think Daisy's color order problems are in non-NEON ARM assembly. > NEON might actually be fine. > > BUG=skia:1843 > > Committed: https://skia.googlesource.com/skia/+/a121c0ee6b911dd7004c6054a8692d37084b6b3d TBR=mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:1843 Review URL: https://codereview.chromium.org/1058173002
* Try ARMv7 and NEON for Daisy.Gravatar Mike Klein2015-04-02
| | | | | | | | | I think Daisy's color order problems are in non-NEON ARM assembly. NEON might actually be fine. BUG=skia:1843 Review URL: https://codereview.chromium.org/1054233002
* back to plain arm for the nightGravatar Mike Klein2015-04-02
| | | | | | | | | | It's looking like the previous CL did not fix the Daisy bot GMs, even though that's still the only bit of code I can find that was ignoring color order. Puzzled. Reverting arm_version=7 for now. BUG=skia:1843 Review URL: https://codereview.chromium.org/1051423002
* Add documentation for tree sheriffsGravatar rmistry2015-04-02
| | | | | | | | BUG=skia: NOTRY=true DOCS_PREVIEW= https://skia.org/?cl=1057883002 Review URL: https://codereview.chromium.org/1057883002
* Test SkCodec to kIndex8 in nanobench.Gravatar scroggo2015-04-02
| | | | | | | BUG=skia:3257 BUG=skia:3475 Review URL: https://codereview.chromium.org/1051973002
* Add a method to read a stream without advancing it.Gravatar scroggo2015-04-02
| | | | | | | | | | | | | | | | | | | | | Add a virtual method on SkStream which will do a "peek" some bytes, so that those bytes are read, but the next call to read will be unaffected. Implement peek for SkMemoryStream, where the implementation is simple and obvious. Implement peek on SkFrontBufferedStream. Add tests. Motivated by decoding streams which cannot be rewound. TBR=reed@google.com BUG=skia:3257 Review URL: https://codereview.chromium.org/1044953002
* experimental speedup some xfermodes with Sk4fGravatar reed2015-04-02
| | | | | | | | | | | | | | | | | | | | | | Old: 7M 1 11.1ms 11.3ms 11.3ms 11.6ms 1% ▅▄▂▂▁▁▄▄█▇ 8888 Xfermode_Screen 7M 1 10.7ms 10.9ms 10.9ms 11.1ms 1% ▄▄▄▇▃▁█▄▂▅ 8888 Xfermode_Modulate 7M 1 7.86ms 8.03ms 8ms 8.18ms 1% █▇▅▁▃▃▂▃▆▅ 8888 Xfermode_Plus 7M 1 14.6ms 14.8ms 14.8ms 15.1ms 1% ▄█▆▅▄▁▁▆▄▆ 8888 Xfermode_Xor 7M 1 13ms 13.5ms 13.4ms 13.8ms 2% ▅▃▇▁█▂▃▅▃▅ 8888 Xfermode_DstATop 7M 1 13.1ms 13.4ms 13.3ms 13.6ms 1% ▄▁▁▆▅▄▇▆█▂ 8888 Xfermode_SrcATop New: 7M 1 6.99ms 7.19ms 7.4ms 8.98ms 8% ▁▂▁▃▂█▁▂▂▂ 8888 Xfermode_Screen 7M 1 5.27ms 5.46ms 5.46ms 5.89ms 3% ▁▁▅▁▂█▄▃▄▃ 8888 Xfermode_Modulate 7M 1 6.8ms 7.04ms 7.27ms 8.53ms 8% ▂▁█▁▁▂▂▂▂▇ 8888 Xfermode_Plus 7M 1 9ms 9.2ms 9.33ms 10.5ms 5% ▁█▃▁▂▁▁▁▅▂ 8888 Xfermode_Xor 7M 1 8.34ms 8.57ms 8.73ms 10.6ms 8% ▁▁▁▂▂▂▂▂▂█ 8888 Xfermode_DstATop 7M 1 8.38ms 8.62ms 8.91ms 10.3ms 8% ▁▃▁▂▇▂▁▂▁█ 8888 Xfermode_SrcATop Need to define SK_SUPPORT_LEGACY_SCALAR_XFERMODES in chrome to suppress change (see https://codereview.chromium.org/1054083002/) Review URL: https://codereview.chromium.org/1043413002
* I suspect S32A_D565_Opaque_neon for Daisy problems.Gravatar Mike Klein2015-04-02
| | | | | | | | | | | I don't see any color-order handling logic in the 32-bit code. BUG=skia:1843 CQ_EXCLUDE_TRYBOTS=client.skia.compile:Build-Win-MSVC-x86-Debug-Trybot,Build-Win-MSVC-x86_64-Debug-Trybot R=mtklein@google.com Review URL: https://codereview.chromium.org/1051683003
* Add test font for large glyphs.Gravatar bungeman2015-04-02
| | | | | | | | This font contains two glyphs, one for 'a' and one for 'A'. The em size is 128, and the 'a' fits in this. The big 'A', however, is ~3000 in in each direction. Review URL: https://codereview.chromium.org/1016153002
* Remove all code related to NaClGravatar borenet2015-04-02
| | | | | | | BUG=skia:3600 DOCS_PREVIEW= https://skia.org/?cl=1036283002 Review URL: https://codereview.chromium.org/1036283002
* SkPMFloat: fewer internal this->isValid() assertions.Gravatar mtklein2015-04-02
| | | | | | | | | | | | | Each of these conversion functions now only asserts is output is valid. For SkPMColor -> SkPMFloat, we assert isValid(). For SkPMFloat -> SkPMColor, we SkPMColorAssert. #floats BUG=skia: BUG=skia:3592 Review URL: https://codereview.chromium.org/1055093002
* Add constant color GrFP.Gravatar bsalomon2015-04-02
| | | | | | Committed: https://skia.googlesource.com/skia/+/dfbbec436cbcacc3270d4b28357c8393e67d6494 Review URL: https://codereview.chromium.org/978713002
* Streamline Thumb config.Gravatar mtklein2015-04-02
| | | | | | | | Enable Thumb2 iff ARM v7. (We don't turn it on today for ARM <v7, and ARM v8 doesn't support it.) BUG=skia: Review URL: https://codereview.chromium.org/1054993002
* Make Daisy ARMv7.Gravatar mtklein2015-04-02
| | | | | | | | | This should be a ~noop as far as gold.skia.org goes. After this, I'll try out NEON. BUG=skia:1843 Review URL: https://codereview.chromium.org/1056793004
* tidy up chromeos_setup.shGravatar mtklein2015-04-02
| | | | | | | | | | | | | | | | | | | | | | | | - remove unused alex - streamline Link's config - remove misleading Daisy config: 1) armv7=1 does nothing. We meant to type arm_version=7 here. 2) arm_neon=1 does nothing unless arm_version == 7. 3) arm_thumb=0 is the default when arm_version <= 7. 4) skia_arch_width=32 is the default when skia_arch_type=arm. I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and arm_thumb=1, which I'm going to separately make the default for arm_version=7), but there are known color-order bugs with our NEON procs that would make Daisy start pushing bad images to Gold. Going to take baby steps here... BUG=skia:1843 Committed: https://skia.googlesource.com/skia/+/3c2809bc612f4a265770914f860d214c9665dc4a CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-CrOS_Daisy-Trybot Review URL: https://codereview.chromium.org/1051253002
* Rename GrBitmapTextContextB to GrAtlasTextContextGravatar joshualitt2015-04-02
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1050173002
* Revert of tidy up chromeos_setup.sh (patchset #1 id:1 of ↵Gravatar mtklein2015-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1051253002/) Reason for revert: arm_thumb not defined Original issue's description: > tidy up chromeos_setup.sh > > - remove unused alex > - streamline Link's config > - remove misleading Daisy config: > 1) armv7=1 does nothing. We meant to type arm_version=7 here. > 2) arm_neon=1 does nothing unless arm_version == 7. > 3) arm_thumb=0 is the default when arm_version <= 7. > 4) skia_arch_width=32 is the default when skia_arch_type=arm. > > I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and > arm_thumb=1, which I'm going to separately make the default for > arm_version=7), but there are known color-order bugs with our > NEON procs that would make Daisy start pushing bad images to > Gold. Going to take baby steps here... > > BUG=skia:1843 > > Committed: https://skia.googlesource.com/skia/+/3c2809bc612f4a265770914f860d214c9665dc4a TBR=borenet@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:1843 Review URL: https://codereview.chromium.org/1059443002
* tidy up chromeos_setup.shGravatar mtklein2015-04-02
| | | | | | | | | | | | | | | | | | | | - remove unused alex - streamline Link's config - remove misleading Daisy config: 1) armv7=1 does nothing. We meant to type arm_version=7 here. 2) arm_neon=1 does nothing unless arm_version == 7. 3) arm_thumb=0 is the default when arm_version <= 7. 4) skia_arch_width=32 is the default when skia_arch_type=arm. I'd just fix this to make Daisy arm_version=7 and arm_neon=1 (and arm_thumb=1, which I'm going to separately make the default for arm_version=7), but there are known color-order bugs with our NEON procs that would make Daisy start pushing bad images to Gold. Going to take baby steps here... BUG=skia:1843 Review URL: https://codereview.chromium.org/1051253002
* Revert of Add constant color GrFP. (patchset #10 id:180001 of ↵Gravatar bsalomon2015-04-02
| | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/978713002/) Reason for revert: Revert while investigating assertions. Original issue's description: > Add constant color GrFP. > > Committed: https://skia.googlesource.com/skia/+/dfbbec436cbcacc3270d4b28357c8393e67d6494 TBR=egdaniel@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1055023002
* Skip desk_baidu skp on Valgrind botGravatar borenet2015-04-02
| | | | | | | | | This has been running for 16 hours: https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Valgrind/builds/12/ BUG=skia:3506 Review URL: https://codereview.chromium.org/1056883002
* pass legal premul values to bitmap -- do we still need this GM?Gravatar reed2015-04-02
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1052083004
* Implement approx-match support in image filter saveLayer() offscreen.Gravatar senorblanco2015-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the GPU-side image filter implementation creates exact-match textures for the offscreen backing stores for saveLayer(). This is because several filters have GPU implementations which depend on the texture coordinates being 0..1. The fix is three-fold: 1) Store the actual requested size in the SkGpuDevice, so that when wrapping it in an SkBitmap for passing to filterImage(), we can give it the original size. 2) Fix the filters (SkMagnifierImageFilter, SkLightingImageFilter, SkMatrixConvolutionImageFilter, SkMatrixImageFilter) whose GPU implementation depends on 0..1 texture coordinates. 3) Remove the exception for GPU-side image filters in SkCanvas::internalSaveLayer(). For the lighting filters, there were two bugs which were cancelling each other out: the sobel filter matrix was being computed upside down, but then we'd negate the resulting normal. This worked fine in the exact-match case, but in the approx-match case we'd sample garbage along the edge pixels. Also, we never implemented the edge pixels according to spec in the GPU case. It requires a different fragment shader for each edge of the nine-patch, which meant we couldn't use asFragmentProcessor(), and had to implement the drawing via a filterImageGPU() override. In order to avoid polluting the public API, I inserted a new base class, SkLightingImageFilterInternal above Sk[Diffuse|Specular]LightingImageFilter to handle the implementation. For the SkMatrixConvolutionImageFilter, it seems the GLSL clamp() function occasionally returns values outside the clamped range, resulting in access of garbage texels even in GL_NEAREST. The fix here is to clamp to a rect inset by half a texel. There was also a bug in the unpremultiply step when fConvolveAlpha is false. For SkMatrixImageFilter, the fix was to make the generic draw path be more careful about when to use texture domain. If the bitmap already has a texture, use texture domain if the srcRect is smaller than the entire texture (not the entire bitmap). N.B.: this change will cause some minor pixel diffs in the GPU results of the following GMs (and possibly more): matriximagefilter, matrixconvolution, imagefiltersscaled, lighting, imagemagnifier, filterfastbounds, complexclip_aa_Layer_invert, complexclip_aa_layer, complexclip_bw_layer_invert, complexclip_bw_layer. BUG=skia:3532 Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9 Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641 Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c Review URL: https://codereview.chromium.org/1034733002
* [SkDebugger] Flatten drawPicture opsGravatar fmalita2015-04-01
| | | | | | | Add two drawPicture bracketing ops (BeginDrawPicture, EndDrawPicture) to replace the current DrawPicture op, and flatten picture contents. Review URL: https://codereview.chromium.org/1048383002
* Revert of Implement approx-match support in image filter saveLayer() ↵Gravatar rmistry2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | offscreen. (patchset #31 id:590001 of https://codereview.chromium.org/1034733002/) Reason for revert: Spoke to Stephen about this. Reverting because failing debug builds: https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51 https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54 Original issue's description: > Implement approx-match support in image filter saveLayer() offscreen. > > Currently, the GPU-side image filter implementation creates > exact-match textures for the offscreen backing stores for > saveLayer(). This is because several filters have GPU > implementations which depend on the texture coordinates > being 0..1. > > The fix is three-fold: > > 1) Store the actual requested size in the SkGpuDevice, so > that when wrapping it in an SkBitmap for passing to > filterImage(), we can give it the original size. > 2) Fix the filters (SkMagnifierImageFilter, > SkLightingImageFilter, SkMatrixConvolutionImageFilter, > SkMatrixImageFilter) whose GPU implementation depends on > 0..1 texture coordinates. > 3) Remove the exception for GPU-side image filters in > SkCanvas::internalSaveLayer(). > > For the lighting filters, there were two bugs which were > cancelling each other out: the sobel filter matrix was > being computed upside down, but then we'd negate the > resulting normal. This worked fine in the exact-match case, > but in the approx-match case we'd sample garbage along > the edge pixels. Also, we never implemented the edge pixels > according to spec in the GPU case. It requires a > different fragment shader for each edge of the nine-patch, > which meant we couldn't use asFragmentProcessor(), and had > to implement the drawing via a filterImageGPU() override. > In order to avoid polluting the public API, I inserted a > new base class, SkLightingImageFilterInternal above > Sk[Diffuse|Specular]LightingImageFilter to handle the > implementation. > > For the SkMatrixConvolutionImageFilter, it seems the > GLSL clamp() function occasionally returns values outside > the clamped range, resulting in access of garbage > texels even in GL_NEAREST. The fix here is to clamp to a > rect inset by half a texel. There was also a bug in > the unpremultiply step when fConvolveAlpha is false. > > For SkMatrixImageFilter, the fix was to make the generic > draw path be more careful about when to use texture domain. > If the bitmap already has a texture, use texture domain > if the srcRect is smaller than the entire texture (not > the entire bitmap). > > N.B.: this change will cause some minor pixel diffs in the > GPU results of the following GMs (and possibly more): > matriximagefilter, matrixconvolution, imagefiltersscaled, > lighting, imagemagnifier, filterfastbounds, > complexclip_aa_Layer_invert, complexclip_aa_layer, > complexclip_bw_layer_invert, complexclip_bw_layer. > > BUG=skia:3532 > > Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9 > > Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641 > > Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia:3532 Review URL: https://codereview.chromium.org/1057693002
* Revert of Fix GLSL error on Android. (patchset #2 id:20001 of ↵Gravatar rmistry2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1053873002/) Reason for revert: Spoke to Stephan about this. Reverting because failing debug builds: https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51 https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54 Original issue's description: > Fix GLSL error on Android. > > BUG=skia: > TBR=bsalomon > NOTREECHECKS=true > NOTRY=true > > Committed: https://skia.googlesource.com/skia/+/f90cd8e0e39af02c3826c80366efa3c06e88f642 TBR=bsalomon@google.com,senorblanco@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1056713002
* Fix GLSL error on Android.Gravatar senorblanco2015-04-01
| | | | | | | | | BUG=skia: TBR=bsalomon NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1053873002
* Add constant color GrFP.Gravatar bsalomon2015-04-01
| | | | Review URL: https://codereview.chromium.org/978713002
* nanobench does not need to handle failed rewind.Gravatar scroggo2015-04-01
| | | | | | | | | | | Now that all SkCodecs can rewind (assuming the stream is rewindable), we do not need to special case it. Pointed out by Derek in the code review that added this. TBR=djsollen Review URL: https://codereview.chromium.org/1058633002
* Implement approx-match support in image filter saveLayer() offscreen.Gravatar senorblanco2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the GPU-side image filter implementation creates exact-match textures for the offscreen backing stores for saveLayer(). This is because several filters have GPU implementations which depend on the texture coordinates being 0..1. The fix is three-fold: 1) Store the actual requested size in the SkGpuDevice, so that when wrapping it in an SkBitmap for passing to filterImage(), we can give it the original size. 2) Fix the filters (SkMagnifierImageFilter, SkLightingImageFilter, SkMatrixConvolutionImageFilter, SkMatrixImageFilter) whose GPU implementation depends on 0..1 texture coordinates. 3) Remove the exception for GPU-side image filters in SkCanvas::internalSaveLayer(). For the lighting filters, there were two bugs which were cancelling each other out: the sobel filter matrix was being computed upside down, but then we'd negate the resulting normal. This worked fine in the exact-match case, but in the approx-match case we'd sample garbage along the edge pixels. Also, we never implemented the edge pixels according to spec in the GPU case. It requires a different fragment shader for each edge of the nine-patch, which meant we couldn't use asFragmentProcessor(), and had to implement the drawing via a filterImageGPU() override. In order to avoid polluting the public API, I inserted a new base class, SkLightingImageFilterInternal above Sk[Diffuse|Specular]LightingImageFilter to handle the implementation. For the SkMatrixConvolutionImageFilter, it seems the GLSL clamp() function occasionally returns values outside the clamped range, resulting in access of garbage texels even in GL_NEAREST. The fix here is to clamp to a rect inset by half a texel. There was also a bug in the unpremultiply step when fConvolveAlpha is false. For SkMatrixImageFilter, the fix was to make the generic draw path be more careful about when to use texture domain. If the bitmap already has a texture, use texture domain if the srcRect is smaller than the entire texture (not the entire bitmap). N.B.: this change will cause some minor pixel diffs in the GPU results of the following GMs (and possibly more): matriximagefilter, matrixconvolution, imagefiltersscaled, lighting, imagemagnifier, filterfastbounds, complexclip_aa_Layer_invert, complexclip_aa_layer, complexclip_bw_layer_invert, complexclip_bw_layer. BUG=skia:3532 Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9 Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641 Review URL: https://codereview.chromium.org/1034733002
* That last CL subverted the purpose of the test. Put it back how it was.Gravatar mtklein2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1055633003
* DM: JSON output adds process_max_resident_set_size_MBGravatar halcanary2015-04-01
| | | | Review URL: https://codereview.chromium.org/917943002
* SkPDF: SkPDFGraphicState Lookup hashtabledGravatar halcanary2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Release, running `dm --src skp --config pdf`, I get a speedup of about 1.2%. SkPDFGraphicState class: - Holds the subset of SkPaint that maps to a PDF Graphics State - These fields are easily comparable, making hashtable comparisons easy. SkPDFCanon: - findGraphicState() takes a SkPDFGraphicState, not a SkPaint - fGraphicStateRecords is a SkHashSet, not a SkTDArray SkPDFGraphicState: - mode_for_pdf() replaces logic inside equivalent(), but is only called once per lookup. - emitObject() no longer modifies the SkPDFGraphicState to cache the SkPDFDict stucture. (Since it is de-duped, this get no speedup). - Static Functions that don't use the canon return a plain SkPDFDict now. No need for fPopulated. SkTHash.h - SkHashSet::forall added SkPDFDevice; SkPDFShader - Updated for new SkPDFGraphicState interface. BUG=skia:3585 Review URL: https://codereview.chromium.org/1046293002
* Implicit constructors for SkFunction are much more readable.Gravatar mtklein2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1052663004
* Emulate distance field gamma fix by making glyphs thicker or thinnerGravatar jvanverth2015-04-01
| | | | | | | | | | | | The idea here is that we determine the 0.5 crossover for each row in the gamma table, then invert the mapping to determine which point that maps to in the original range [-.65, .65]. That gives us a change in the apparent width of the glyph that closely corresponds to the change produced by the gamma fix. BUG=skia:2933 Review URL: https://codereview.chromium.org/1042373002
* move Atlas Text Context to its own fileGravatar joshualitt2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1045723010
* Update the Android scripts to refresh device names and capabilities.Gravatar djsollen2015-04-01
| | | | Review URL: https://codereview.chromium.org/1054633002
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-05 14:07:50 +0000