aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core
Commit message (Collapse)AuthorAge
* Straighten out SkPicture::AccelData APIs.Gravatar mtklein2015-04-29
| | | | | | | | | | Must have been we needed them to be weird (mutable, const setter) before. It doesn't look like that's necessary now... we can just pass it to the constructor. BUG=skia: Review URL: https://codereview.chromium.org/1112833003
* SkRWBuffer for thread-safe 'stream' sharingGravatar reed2015-04-28
| | | | | | | | | | | | | WIP - Can accumulate (write) data in one thread, and share snapshots of it in other threads ... e.g. network accumulates image data, and periodically we want to decode/draw it - If this sort of thing sticks, should we promote SkData to have the same generality as SkRBuffer? BUG=skia: TBR= Review URL: https://codereview.chromium.org/1106113002
* Fix SkTDynamicHash.h:183:29: warning: equality comparison with extraneous ↵Gravatar dongseong.hwang2015-04-28
| | | | | | parentheses [-Wparentheses-equality] Review URL: https://codereview.chromium.org/1115433004
* Decrement SkCanvas::fDeferredSaveCount in doSave()Gravatar fmalita2015-04-28
| | | | | | | | | | | | We're currently decrementing early in checkForDeferredSave(), but that means we break the getSaveCount() invariant during willSave() dispatch. Instead, we can defer to doSave(), until after willSave() is called. This allows overriders to call getSaveCount(). R=reed@google.com,robertphillips@google.com Review URL: https://codereview.chromium.org/1113603002
* De-proc Color32Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | | | | Also strips SK_SUPPORT_LEGACY_COLOR32_MATH, which is no longer needed. Seems handy to have SkTypes include the relevant intrinsics when we know we've got them, but I'm not married to it. Locally this looks like a pointlessly small perf win, but I'm mostly keen to get all the code together. BUG=skia: Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72b Committed: https://skia.googlesource.com/skia/+/d65dc0cedd5b50dd407b6ff8fdc39123f11511cc CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Mips-Debug-Android-Trybot Review URL: https://codereview.chromium.org/1104183004
* Revert of De-proc Color32 (patchset #5 id:80001 of ↵Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1104183004/) Reason for revert: duh Original issue's description: > De-proc Color32 > > Also strips SK_SUPPORT_LEGACY_COLOR32_MATH, > which is no longer needed. > > Seems handy to have SkTypes include the relevant intrinsics when > we know we've got them, but I'm not married to it. > > Locally this looks like a pointlessly small perf win, but I'm mostly > keen to get all the code together. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72b > > Committed: https://skia.googlesource.com/skia/+/d65dc0cedd5b50dd407b6ff8fdc39123f11511cc TBR=reed@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1102363006
* De-proc Color32Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | Also strips SK_SUPPORT_LEGACY_COLOR32_MATH, which is no longer needed. Seems handy to have SkTypes include the relevant intrinsics when we know we've got them, but I'm not married to it. Locally this looks like a pointlessly small perf win, but I'm mostly keen to get all the code together. BUG=skia: Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72b Review URL: https://codereview.chromium.org/1104183004
* Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARMGravatar mtklein2015-04-27
| | | | | | | | | | | | This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after. BUG=skia: Committed: https://skia.googlesource.com/skia/+/9de16283fdc8cc0d31a84f503578d0ecea4e8297 CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot Review URL: https://codereview.chromium.org/1109913002
* Revert of De-proc Color32 (patchset #4 id:60001 of ↵Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1104183004/) Reason for revert: MIPS Original issue's description: > De-proc Color32 > > Also strips SK_SUPPORT_LEGACY_COLOR32_MATH, > which is no longer needed. > > Seems handy to have SkTypes include the relevant intrinsics when > we know we've got them, but I'm not married to it. > > Locally this looks like a pointlessly small perf win, but I'm mostly > keen to get all the code together. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72b TBR=reed@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1108163002
* De-proc Color32Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | Also strips SK_SUPPORT_LEGACY_COLOR32_MATH, which is no longer needed. Seems handy to have SkTypes include the relevant intrinsics when we know we've got them, but I'm not married to it. Locally this looks like a pointlessly small perf win, but I'm mostly keen to get all the code together. BUG=skia: Review URL: https://codereview.chromium.org/1104183004
* Revert of Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision ↵Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | | | | | | | on ARM (patchset #2 id:20001 of https://codereview.chromium.org/1109913002/) Reason for revert: arm64 typos Original issue's description: > Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM > > This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/9de16283fdc8cc0d31a84f503578d0ecea4e8297 TBR=reed@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1105233003
* Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARMGravatar mtklein2015-04-27
| | | | | | | | This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after. BUG=skia: Review URL: https://codereview.chromium.org/1109913002
* Mike's radial gradient CL with better float -> int.Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001) This looks quite launchable. radial_gradient3, min of 100 samples: N5: 985µs -> 946µs MBP: 395µs -> 279µs On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table? BUG=skia: CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.8-Clang-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm7-Release-Android_NoNeon-Trybot Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec Review URL: https://codereview.chromium.org/1109643002
* Revert of Mike's radial gradient CL with better float -> int. (patchset #7 ↵Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:120001 of https://codereview.chromium.org/1109643002/) Reason for revert: compile failures. Original issue's description: > Mike's radial gradient CL with better float -> int. > > patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001) > > This looks quite launchable. radial_gradient3, min of 100 samples: > N5: 985µs -> 946µs > MBP: 395µs -> 279µs > > On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table? > > BUG=skia: > > CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot > > Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec TBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1109883003
* Mike's radial gradient CL with better float -> int.Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001) This looks quite launchable. radial_gradient3, min of 100 samples: N5: 985µs -> 946µs MBP: 395µs -> 279µs On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table? BUG=skia: CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot Review URL: https://codereview.chromium.org/1109643002
* Reduce ref counting in SkPictureRecorder.Gravatar mtklein2015-04-27
| | | | | | | | | | | | | | | | This may be a small help to slimming paint: picture_overhead_draw 1.25us -> 1.22us 0.98x picture_overhead_nodraw 318ns -> 276ns 0.87x It certainly cannot hurt performance. BUG=chromium:470553 TBR=reed@google.com No public API changes. Review URL: https://codereview.chromium.org/1098183003
* Reduce sizeof(SkPicture::Analysis) from 24 bytes to 2 bytes.Gravatar jbroman2015-04-27
| | | | | | | | | | | | | | | | | | This saves "up to" 22 bytes per SkPicture. Due to alignment, this reduces sizeof(SkPicture): - from 88 to 72 bytes on Linux x64 - from 68 to 48 bytes on Android (with Chrome's build settings) It also somewhat simplifies the GPU veto logic. BUG=skia: [mtklein] No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1060863004
* Cleanup: Remove unnecessary double-semicolons.Gravatar tfarina2015-04-27
| | | | | | | | | | | | | | | The entries were found by the following command line: $ find . -regex ".*\.[cChH]\(pp\)?" | xargs git grep -e ';;' --and --not -e 'for *(.*;;' Which is a combination of http://stackoverflow.com/a/3858879 and http://gitster.livejournal.com/27674.html BUG=None R=mtklein@google.com Review URL: https://codereview.chromium.org/1088763005
* Fix some lingering typosGravatar robertphillips2015-04-24
| | | | Review URL: https://codereview.chromium.org/1101293003
* Remove MSAA check from Ganesh veto (dashed paths are no longer slow).Gravatar senorblanco2015-04-22
| | | | | | | R=egdaniel@google.com BUG=skia: Review URL: https://codereview.chromium.org/1098753004
* O(1) SkPictureUtils::ApproxBytesUsed()Gravatar mtklein2015-04-21
| | | | | | | | | | Chrome wants to call this more often, and it's quite slow today. Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed(). BUG=chromium:471873 Review URL: https://codereview.chromium.org/1090943004
* Revert of Convert Color32 code to perfect blend. (patchset #6 id:100001 of ↵Gravatar mtklein2015-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1098913002/) Reason for revert: Xfermode_SrcOver not looking encouraging. Up to 50% regressions. https://perf.skia.org/#3242 Original issue's description: > Convert Color32 code to perfect blend. > > Before we commit to blend_256_round_alt, let's make sure blend_perfect is > really slower in practice (i.e. regresses on perf.skia.org). > > blend_perfect is really the most desirable algorithm if we can afford it. Not > only is it correct, but it's easy to think about and break into correct pieces: > for instance, its div255() doesn't require any coordination with the multiply. > > This looks like a 30% hit according to microbenches. That said, microbenches > said my previous change would be a 20-25% perf improvement, but it didn't end > up showing a significant effect at a high level. > > As for correctness, I see a bunch of off-by-1 compared to blend_256_round_alt > (exactly what we'd expect), and one off-by-3 in a GM that looks like it has a > bunch of overdraw. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/61221e7f87a99765b0e034020e06bb018e2a08c2 TBR=reed@google.com,fmalita@chromium.org,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1083923006
* SkTHash: remove()Gravatar mtklein2015-04-21
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1057043003
* Convert Color32 code to perfect blend.Gravatar mtklein2015-04-20
| | | | | | | | | | | | | | | | | | | | | Before we commit to blend_256_round_alt, let's make sure blend_perfect is really slower in practice (i.e. regresses on perf.skia.org). blend_perfect is really the most desirable algorithm if we can afford it. Not only is it correct, but it's easy to think about and break into correct pieces: for instance, its div255() doesn't require any coordination with the multiply. This looks like a 30% hit according to microbenches. That said, microbenches said my previous change would be a 20-25% perf improvement, but it didn't end up showing a significant effect at a high level. As for correctness, I see a bunch of off-by-1 compared to blend_256_round_alt (exactly what we'd expect), and one off-by-3 in a GM that looks like it has a bunch of overdraw. BUG=skia: Review URL: https://codereview.chromium.org/1098913002
* Now, path ops natively intersect conics, quads, and cubics in any ↵Gravatar caryclark2015-04-20
| | | | | | | | | | | combination. There are still a class of cubic tests that fail and a handful of undiagnosed failures from skps and fuzz tests, but things are much better overall. Extended tests (150M+) run to completion in release in about 6 minutes; the standard test suite exceeds 100K and finishes in a few seconds on desktops. TBR=reed BUG=skia:3588 Review URL: https://codereview.chromium.org/1037953004
* apply xfermode after imagefilter when we create a tmp layerGravatar reed2015-04-20
| | | | | | BUG=skia:3741 Review URL: https://codereview.chromium.org/1091173003
* remove dead code from SK_SUPPORT_LEGACY_BLITANTIH2V2Gravatar reed2015-04-20
| | | | | | | | | no image changes expected in skia or chrome/blink BUG=skia: TBR= Review URL: https://codereview.chromium.org/1050953003
* Trace contention for lockPixels mutexGravatar enne2015-04-17
| | | | Review URL: https://codereview.chromium.org/1090103002
* Rework SSE and NEON Color32 algorithms to be more correct and faster.Gravatar mtklein2015-04-17
| | | | | | | | | | | | | | | | | | | | This algorithm changes the blend math, guarded by SK_LEGACY_COLOR32_MATH. The new math is more correct: it's never off by more than 1, and correct in all the interesting 0x00 and 0xFF edge cases, where the old math was never off by more than 2, and not always correct on the edges. If you look at tests/BlendTest.cpp, the old code was using the `blend_256_plus1_trunc` algorithm, while the new code uses `blend_256_round_alt`. Neither uses `blend_perfect`, which is about ~35% slower than `blend_256_round_alt`. This will require an unfathomable number of rebaselines, first to Skia, then to Blink when I remove the guard. I plan to follow up with some integer SIMD abstractions that can unify these two implementations into a single algorithm. This was originally what I was working on here, but the correctness gains seem to be quite compelling. The only places these two algorithms really differ greatly now is the kernel function, and even there they can really both be expressed abstractly as: - multiply 8-bits and 8-bits producing 16-bits - add 16-bits to 16-bits, returning the top 8 bits. All the constants are the same, except SSE is a little faster to keep 8 16-bit inverse alphas, NEON's a little faster to keep 8 8-bit inverse alphas. I may need to take this small speed win back to unify the two. We should expect a ~25% speedup on Intel (mostly from unrolling to 8 pixels) and a ~20% speedup on ARM (mostly from using vaddhn to add `color`, round, and narrow back down to 8-bit all into one instruction. (I am probably missing several more related bugs here.) BUG=skia:3738,skia:420,chromium:111470 Review URL: https://codereview.chromium.org/1092433002
* Remove filename from SkFontDescriptor.Gravatar bungeman2015-04-17
| | | | | | | | | | No one actually uses it, so remove it. Keep the string id for backward compatibility. TBR=reed@google.com This doesn't change any public API. Review URL: https://codereview.chromium.org/1057413005
* Don't serialize anything for SkEmptyShader.Gravatar mtklein2015-04-16
| | | | | | BUG=skia:3735 Review URL: https://codereview.chromium.org/1097433002
* remove older version of cubic->coeffGravatar reed2015-04-15
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1084623004
* Speeup hairline curves (quads and cubics) (patchset #7 id:120001 of ↵Gravatar reed2015-04-15
| | | | | | | | | | | | | https://codereview.chromium.org/1078413003/)" ah ha! Check for the define *after* we pull in SkUserConfig.h (indirectly) This reverts commit 639a82855b94b93c4fa45560e67df8ec4a8bbb3a. BUG=skia: TBR= Review URL: https://codereview.chromium.org/1084283003
* Revert of make blitAntiH2 virtual, to prep for larger change (patchset #1 ↵Gravatar reed2015-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | id:1 of https://codereview.chromium.org/1048323005/) Reason for revert: end of test Original issue's description: > make blitAntiH2 virtual, to prep for larger change > > testing... > > BUG=skia: > TBR= > > Committed: https://skia.googlesource.com/skia/+/33afdaa5213cf118b3ca290bb343253c8593756d TBR= NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1086293002
* make blitAntiH2 virtual, to prep for larger changeGravatar reed2015-04-15
| | | | | | | | | testing... BUG=skia: TBR= Review URL: https://codereview.chromium.org/1048323005
* Revert of Speeup hairline curves (quads and cubics) (patchset #7 id:120001 ↵Gravatar reed2015-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of https://codereview.chromium.org/1078413003/) Reason for revert: Crazy failings in chrome tests http://build.chromium.org/p/client.skia/builders/Linux%20Tests/builds/1862 Original issue's description: > Speeup hairline curves (quads and cubics) > > /skia/trunk> cat ../old.txt > maxrss loops min median mean max stddev samples config bench > 9M 1 4.28ms 4.32ms 4.36ms 4.67ms 3% ▄▁▁▃▂▂▁▁▂█ 8888 path_hairline_small_AA_cubic > 9M 1 743µs 767µs 770µs 825µs 4% ▃▃▇▃▁▁▅▁█▁ 8888 path_hairline_small_AA_conic > 9M 1 533µs 606µs 598µs 680µs 9% ▁▂▂█▆▇▇▄▂▂ 8888 path_hairline_small_AA_quad > 9M 1 451µs 452µs 456µs 495µs 3% ▁▁▁▁█▁▁▁▁▁ 8888 path_hairline_small_AA_line > > /skia/trunk> cat ../new.txt > maxrss loops min median mean max stddev samples config bench > 9M 1 827µs 827µs 831µs 869µs 2% ▁▁▁▁▁▁▁█▁▁ 8888 path_hairline_small_AA_cubic > 9M 1 515µs 517µs 517µs 518µs 0% ▇█▆▅▃▃▁▁▁▅ 8888 path_hairline_small_AA_conic > 9M 1 310µs 311µs 315µs 332µs 2% ▂▁█▆▁▁▁▁▁▁ 8888 path_hairline_small_AA_quad > 9M 1 254µs 254µs 258µs 276µs 3% ▁▁▁▁▁▁▁█▇▂ 8888 path_hairline_small_AA_line > > Edited revert of https://codereview.chromium.org/1085013003 > > TBR= > > Expectations: > - no effect on chrome, as it is guarded > - lots of tiny rebaselines for skia TBR= NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1092483003
* Speeup hairline curves (quads and cubics)Gravatar reed2015-04-15
| | | | | | | | | | | | | | | | | | | | | | /skia/trunk> cat ../old.txt maxrss loops min median mean max stddev samples config bench 9M 1 4.28ms 4.32ms 4.36ms 4.67ms 3% ▄▁▁▃▂▂▁▁▂█ 8888 path_hairline_small_AA_cubic 9M 1 743µs 767µs 770µs 825µs 4% ▃▃▇▃▁▁▅▁█▁ 8888 path_hairline_small_AA_conic 9M 1 533µs 606µs 598µs 680µs 9% ▁▂▂█▆▇▇▄▂▂ 8888 path_hairline_small_AA_quad 9M 1 451µs 452µs 456µs 495µs 3% ▁▁▁▁█▁▁▁▁▁ 8888 path_hairline_small_AA_line /skia/trunk> cat ../new.txt maxrss loops min median mean max stddev samples config bench 9M 1 827µs 827µs 831µs 869µs 2% ▁▁▁▁▁▁▁█▁▁ 8888 path_hairline_small_AA_cubic 9M 1 515µs 517µs 517µs 518µs 0% ▇█▆▅▃▃▁▁▁▅ 8888 path_hairline_small_AA_conic 9M 1 310µs 311µs 315µs 332µs 2% ▂▁█▆▁▁▁▁▁▁ 8888 path_hairline_small_AA_quad 9M 1 254µs 254µs 258µs 276µs 3% ▁▁▁▁▁▁▁█▇▂ 8888 path_hairline_small_AA_line Edited revert of https://codereview.chromium.org/1085013003 TBR= Review URL: https://codereview.chromium.org/1078413003
* SkPDF/Device/ImageFilter: Fix ImageFilter fallback codeGravatar halcanary2015-04-15
| | | | | | | | | | Broken in https://chromium.googlesource.com/skia/+/76033be I have confirmed that this fixes 470083. BUG=470083 Review URL: https://codereview.chromium.org/1080923004
* add blitter api for aa-hairlinesGravatar reed2015-04-15
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1088143002
* Revert of add new blit2 methods in support of antialiased hairlines guard ↵Gravatar jcgregorio2015-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flag SK_SUPPORT_LEGACY_BLITANTIH2V2 (patchset #2 id:20001 of https://codereview.chromium.org/1060153003/) Reason for revert: DEPS roll is failing, one such example: http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel/builds/73847/steps/ash_unittests%20%28with%20patch%29/logs/stdio More here: https://codereview.chromium.org/1091483003 This CL was the only CL in the roll when things started to fail. Original issue's description: > add new blit2 methods in support of antialiased hairlines > > before: > 9M 1 528µs 530µs 539µs 607µs 5% ▁▁▁▁▁▁▁▁█▂ 8888 path_hairline_small_AA_quad > > after: > 9M 1 355µs 356µs 358µs 375µs 2% ▂▁▁▁▁▁▁▁▁█ 8888 path_hairline_small_AA_quad > > BUG=skia: > > does require new baselines (bug chrome is guarded) > > Committed: https://skia.googlesource.com/skia/+/dd83031b98db4c6d3d0de2353bf115152a7d1464 TBR=caryclark@google.com,reed@chromium.org,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1085013003
* add new blit2 methods in support of antialiased hairlinesGravatar reed2015-04-14
| | | | | | | | | | | | | | before: 9M 1 528µs 530µs 539µs 607µs 5% ▁▁▁▁▁▁▁▁█▂ 8888 path_hairline_small_AA_quad after: 9M 1 355µs 356µs 358µs 375µs 2% ▂▁▁▁▁▁▁▁▁█ 8888 path_hairline_small_AA_quad BUG=skia: does require new baselines (bug chrome is guarded) Review URL: https://codereview.chromium.org/1060153003
* Sk4h and Sk8h for SSEGravatar mtklein2015-04-14
| | | | | | | | | | These will underly the SkPMFloat-like class for uint16_t components. Sk4h will back a single-pixel version, and Sk8h any larger number than that. BUG=skia: Review URL: https://codereview.chromium.org/1088883005
* Start canonicalizing color for all A8 textblobsGravatar joshualitt2015-04-14
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1076593002
* Rename SkNi to SkNb.Gravatar mtklein2015-04-14
| | | | | | | | | | | | | | | | As used today, SkNi is used in bool-y contexts. This keeps that, but under a new name, SkNb. This makes room for a new SkNi that's focused on integer-y things like loads, stores, arithmetic, etc. The main reason to split these is that we want different specializations for each use case: for bools, it's important for us to specialize 32- and 64-bit to support efficient float- and double- comparisons, but for integer work we're more likely to be looking at 8- and 16- bit lanes. Keeping these use cases siloed helps me manage the compexity of the backend NEON and SSE code. BUG=skia: Review URL: https://codereview.chromium.org/1083123002
* change hairline procs to take array of pointsGravatar reed2015-04-14
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1085883002
* Fix minor undercounting in SkRecord::bytesUsed().Gravatar mtklein2015-04-13
| | | | | | | | | | | | | | | | | | When an SkRecord has more than kInlineRecords ops in it (today, 5 or more), the current logic undercounts the bytes used by the SkRecord by sizeof(Record) * kInlineRecords, i.e. 32 bytes. This isn't a huge deal... by the time you've recorded 5 ops, we're typically up around 1KB anyway, and it's only ever off by that constant 32 bytes, so somewhere between 3% to 0% error as the picture grows. But now that I've noticed, we might as well fix it. Basically, this is a reminder that the inline space used to store those first kInlineRecords ops goes to waste once we pass that threshold. In contrast, fInlineAlloc, the space we preallocate for the SkVarAlloc, never goes to waste. It always holds the first few ops' data even when we grow past it. BUG=skia: Review URL: https://codereview.chromium.org/1081433002
* use fast/inline SkRect::set(p0, p1) for 2 pointsGravatar reed2015-04-12
| | | | | | | | | | 10% speedup for clipped haircubics BUG=skia: TBR= NOTRY=True Review URL: https://codereview.chromium.org/1079343002
* setDrawFilter needs to trigger any deferred savesGravatar reed2015-04-11
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1077353002
* change hairline procs to take SkPoint by value, more efficient on SSE and NEONGravatar reed2015-04-10
| | | | | | | | | precursor for https://codereview.chromium.org/1074313002/ BUG=skia: TBR= Review URL: https://codereview.chromium.org/1084433002
* Add serialization of SkBitmapSource's new filterQuality member variableGravatar robertphillips2015-04-10
| | | | | | Missed this in https://codereview.chromium.org/1072603002/ (Add GM to repro crbug.com/472795) Review URL: https://codereview.chromium.org/1078113002
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-03 02:56:45 +0000