aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* 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
* Ico test with embedded pngGravatar msarett2015-04-01
| | | | | | BUG=skia:3257 Review URL: https://codereview.chromium.org/1054673002
* Add timing SkCodec to nanobench.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CodecBench: Add new class for timing using SkCodec. DecodingBench: Include creating a decoder inside the loop. This is to have a better comparison against SkCodec. SkCodec's factory function does not necessarily read the same amount as SkImageDecoder's, so in order to have a meaningful comparison, read the entire stream from the beginning. Also for comparison, create a new SkStream from the SkData each time. Add a debugging check to make sure we have an SkImageDecoder. Add include guards. nanobench.cpp: Decode using SkCodec. When decoding using SkImageDecoder, exclude benches where we decoded to a different color type than requested. SkImageDecoder may decide to decode to a different type, in which case the name is misleading. TODOs: Now that we ignore color types that do not match the desired color type, we should add Index8. This also means calling the more complex version of getPixels so CodecBench can support kIndex8. BUG=skia:3257 Review URL: https://codereview.chromium.org/1044363002
* Switch to one single bitmap text blob cache allocationGravatar joshualitt2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1041953002
* Constructor and call argument forwarding for SkFunction.Gravatar mtklein2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1050113003
* SkCodec::onGetScanlineDecoder must call rewind.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | | | | | | | This mirrors the behavior in onGetPixels, and allows the implementation to share code for handling calls to rewindIfNeeded. This also fixes a bug where getScanlineDecoder was calling rewindIfNeeded and treating the result as a bool. In SkPngCodec, factor out the code to call rewindIfNeeded, and call it in both onGetPixels and onGetScanlineDecoder. Update the test to include testing the scanline decoder. Rename "gen" to "codec" now that it must be an SkCodec. BUG=skia:3257 Depends on https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUE). Review URL: https://codereview.chromium.org/1050893002
* Add SkTHashSet::find()Gravatar mtklein2015-04-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1058553002
* Revert of Enable both static and dynamically linked libpng (patchset #4 ↵Gravatar djsollen2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | id:60001 of https://codereview.chromium.org/1032253003/) Reason for revert: breaking the nexus_9 and ios builds. Original issue's description: > Enable both static and dynamically linked libpng > > 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. > > Committed: https://skia.googlesource.com/skia/+/2469c999518e7b0063d35e9e2eb074a0477c21ac TBR=scroggo@google.com,msarett@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1050183002
* Enable both static and dynamically linked libpngGravatar djsollen2015-04-01
| | | | | | | | 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/1032253003
* Acknowledge that SkIcoCodec can rewind and test it.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | Since SkIcoCodec has an SkCodec for its encoded images, backed by SkMemoryStreams, the SkMemoryStream can always rewind, and will be rewound by the sub-codec if necessary (now that SkBmpCodec and SkPngCodec support rewinding). Depends on https://codereview.chromium.org/1057483003/ and https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUES). BUG=skia:3257 Review URL: https://codereview.chromium.org/1054603002
* Make SkPngCodec support rewinding properly.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | Separate out the code for reading the header, and use it to reinitialize fPng_ptr and fInfo_ptr after a rewind. Use common code to clean up fPng_ptr and fInfo_ptr, and set them to NULL and treat them as NULL as appropriate. Update the test to expect SkPngCodec to succeed. BUG=skia:3257 Review URL: https://codereview.chromium.org/1048423003
* Find the HASHTAGS file even if you are not at the checkout root.Gravatar rmistry2015-04-01
| | | | | | | | The post upload hook was failing if you were not at the root, this fixes it. NOTRY=true Review URL: https://codereview.chromium.org/1058483002
* small-object optimization for SkFunctionGravatar mtklein2015-04-01
| | | | | | | | Anything <= sizeof(void*) will be inlined, avoiding heap allocation. BUG=skia: Review URL: https://codereview.chromium.org/1048243002
* Handle rewinds in SkBmpCodec.Gravatar scroggo2015-04-01
| | | | | | | | Factor our BMP code for reading the header, and call it after a rewind. BUG=skia:3257 Review URL: https://codereview.chromium.org/1057483003
* Creating a new wrapper for gif decoderGravatar msarett2015-04-01
| | | | | | | BUG=skia:3257 BUG=skia:3534 Review URL: https://codereview.chromium.org/1022673011
* GrGLInterface: Add support for NV_framebuffer_mixed_samplesGravatar vbuzinov2015-04-01
| | | | | | | | | Import glCoverageModulation if NV_framebuffer_mixed samples is available BUG=skia:3177 Review URL: https://codereview.chromium.org/993363002
* Revert of Implement approx-match support in image filter saveLayer() ↵Gravatar rmistry2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | offscreen. (patchset #27 id:510001 of https://codereview.chromium.org/1034733002/) Reason for revert: Looks like this change is causing layout test failures which is blocking Skia's DEPS roll into Chromium: https://codereview.chromium.org/1050563002/ https://codereview.chromium.org/1043133005/ https://codereview.chromium.org/1048273002/ Reverting to see if this fixes the DEPS roll. 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) 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. > > 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 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/1057443003
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 21:44:12 +0000