Renames Sk4pxXfermode.h to SkXfermode_opts.h,
and refactors it a tiny bit internally.
This moves xfermode optimization from being "compile-time everywhere but NEON"
to simply "runtime everywhere". I don't anticipate any effect on perf or
correctness.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264543006
With this new arrangement, the benefits of inlining sk_memset16/32 have changed.
On x86, they're not significantly different, except for small N<=10 where the inlined code is significantly slower.
On ARMv7 with NEON, our custom code is still significantly faster for N>10 (up to 2x faster). For small N<=10 inlining is still significantly faster.
On ARMv7 without NEON, our custom code is still ridiculously faster (up to 10x) than inlining for N>10, though for small N<=10 inlining is still a little faster.
We were not using the NEON memset16 and memset32 procs on ARMv8. At first blush, that seems to be an oversight, but if so it's an extremely lucky one. The ARMv8 code generation for our memset16/32 procs is total garbage, leaving those methods ~8x slower than just inlining the memset, using the compiler's autovectorization.
So, no need to inline any more on x86, and still inline for N<=10 on ARMv7. Always inline for ARMv8.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1270573002
This enables the NEON sk_float_rsqrt() code for configurations that have NEON at run-time but not compile-time.
These devices will see about a 2x (1.26 -> 2.33) slowdown in sk_float_rsqrt(), but it should be more precise than our portable fallback.
(When inlined, the portable fallback and the NEON code are almost identical in speed. The only difference is precision. Going through a function pointer is causing all this slowdown. This is a good example of a place where Skia really benefits from compile-time NEON.)
BUG=skia:4117,skia:4114
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1264893002
This hasn't been tested for years, and no one currently knows when it
last worked (if ever). It is doubtful that any of the remaining logic
would even make sense with a modern version of Embedded Compact 2013.
Review URL: https://codereview.chromium.org/1260453008
Improves max relative error from 0.00175126 to 0.000650197.
Also add unit tests to check error bounds.
BUG=chromium:511458
Review URL: https://codereview.chromium.org/1251423002
Tidy up a little while I'm in here:
1) SIMD headers are now included by SkTypes.h as appropriate.
2) _mm_cvtss_f32() is pithier and generates the same code.
Looks like this is the only code checking for SSE wrong. After this CL:
~/skia (sse) $ git grep __SSE
include/core/SkPreConfig.h: #if defined(__SSE4_2__)
include/core/SkPreConfig.h: #elif defined(__SSE4_1__)
include/core/SkPreConfig.h: #elif defined(__SSE3__)
include/core/SkPreConfig.h: #elif defined(__SSE2__)
every other check is in SkPreConfig.h where it belongs.
This is going to affect some GMs subtly on Windows.
BUG=chromium:511458
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1248503004
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
A careful reading of the preprocessor specification indicates that
any use of the 'defined' operator outside the form of 'defined X' or
'defined ( X )' directly in the constant expression of a '#if' or
'#elif' may cause undefined behavior.
In particular, msvc is very unpredictable. The 'defined X' and
'defined ( X )' forms behave differently when created from marco
expansion, with 'defined ( X )' generally evaluating to '0L'. The
'defined X' form generally behaves more the way one would expect,
but still has a number of quirks which should simply be considered
undefined behavior.
BUG=chromium:419245
Review URL: https://codereview.chromium.org/657183002
This generalizes and shares the solution found for a similar issue with
GDI. The issue is that the text size is applied early, and the rest of
the transformation late. This allows us to isolate and independently
control the text size from the rest of the transformation.
R=reed@google.com
Review URL: https://codereview.chromium.org/213153006
git-svn-id: http://skia.googlecode.com/svn/trunk@14201 2bbb7eff-a529-9590-31e7-b0007b416f81
I have manually examined all of these diffs and restored a few files that
seem to require manual adjustment.
The following files still need to be modified manually, in a separate CL:
android_sample/SampleApp/AndroidManifest.xml
android_sample/SampleApp/res/layout/layout.xml
android_sample/SampleApp/res/menu/sample.xml
android_sample/SampleApp/res/values/strings.xml
android_sample/SampleApp/src/com/skia/sampleapp/SampleApp.java
android_sample/SampleApp/src/com/skia/sampleapp/SampleView.java
experimental/CiCarbonSampleMain.c
experimental/CocoaDebugger/main.m
experimental/FileReaderApp/main.m
experimental/SimpleCocoaApp/main.m
experimental/iOSSampleApp/Shared/SkAlertPrompt.h
experimental/iOSSampleApp/Shared/SkAlertPrompt.m
experimental/iOSSampleApp/SkiOSSampleApp-Base.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Debug.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Release.xcconfig
gpu/src/android/GrGLDefaultInterface_android.cpp
gyp/common.gypi
gyp_skia
include/ports/SkHarfBuzzFont.h
include/views/SkOSWindow_wxwidgets.h
make.bat
make.py
src/opts/memset.arm.S
src/opts/memset16_neon.S
src/opts/memset32_neon.S
src/opts/opts_check_arm.cpp
src/ports/SkDebug_brew.cpp
src/ports/SkMemory_brew.cpp
src/ports/SkOSFile_brew.cpp
src/ports/SkXMLParser_empty.cpp
src/utils/ios/SkImageDecoder_iOS.mm
src/utils/ios/SkOSFile_iOS.mm
src/utils/ios/SkStream_NSData.mm
tests/FillPathTest.cpp
Review URL: http://codereview.appspot.com/4816058
git-svn-id: http://skia.googlecode.com/svn/trunk@1982 2bbb7eff-a529-9590-31e7-b0007b416f81
fix addArc to not wrap around if the sweepAngle is close to 360 but lost
precision when convert to radians (and then to unit vectors ala sin/cos)
git-svn-id: http://skia.googlecode.com/svn/trunk@495 2bbb7eff-a529-9590-31e7-b0007b416f81
