Tweak some test values to pass with floats.
As expected, this regresses matrix44_setconcat_general by about 2x.
BUG=skia:
Review URL: https://codereview.chromium.org/1169813006
This fixes two problems:
1) #include SK_SOME_DEFINE doesn't work well for all our clients.
2) Things in include/ are #including things in src/, which we don't like.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/862983002
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
Every doc I've found about using Android's atomics says, "stop".
"* A handful of basic atomic operations. The appropriate pthread
* functions should be used instead of these whenever possible."
"... we recommend stopping from using these functions entirely. Very fortunately, GCC provides handy intrinsics functions that work with very reasonable performance and always provide a full barrier."
As far as I can tell, there's no code generation change here: both the __sync atomics and the android_ atomics use full memory barriers. (And now with this all unified, it'll be easier to get the real wins by switching everything to __atomic atomics, which are like __sync atomics but allow control over memory barriers.)
BUG=skia:
R=bungeman@google.com, djsollen@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/305593002
git-svn-id: http://skia.googlecode.com/svn/trunk@14896 2bbb7eff-a529-9590-31e7-b0007b416f81
Mike K: please sanity check Test.cpp and skia_test.cpp
Feel free to look at the rest, but I don't expect any in depth review of path ops innards.
Path Ops first iteration used QuickSort to order segments radiating from an intersection to compute the winding rule.
This revision uses a circular sort instead. Breaking out the circular sort into its own long-lived structure (SkOpAngle) allows doing less work and provides a home for caching additional sorting data.
The circle sort is more stable than the former sort, has a robust ordering and fewer exceptions. It finds unsortable ordering less often. It is less reliant on the initial curve tangent, using convex hulls instead whenever it can.
Additional debug validation makes sure that the computed structures are self-consistent. A new visualization tool helps verify that the angle ordering is correct.
The 70+M tests pass with this change on Windows, Mac, Linux 32 and Linux 64 in debug and release.
R=mtklein@google.com, reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/131103009
git-svn-id: http://skia.googlecode.com/svn/trunk@14183 2bbb7eff-a529-9590-31e7-b0007b416f81
Tested in Mozilla source tree. I tried to use skia build system, but it's up to the task for cross compilation.
SkHRESULT.cpp - Use proper file name (that matters on case sensitive OSes)
SkAtomics_win.h - Don't use pragma intrinsic on GCC (this causes massive warnings)
SkOSFile_win.cpp - This one is tricky. GCC doesn't allow (void*) casts in template argument constants and INVALID_HANDLE_VALUE looks like this:
((HANDLE)(LONG_PTR)-1)
where HANDLE is typedefed to void*. Changed the code to use LONG_PTR as template argument and cast it when needed.
BUG=skia:
R=bungeman@google.com, reed@google.com
Author: cjacek@gmail.com
Review URL: https://codereview.chromium.org/198643004
git-svn-id: http://skia.googlecode.com/svn/trunk@13862 2bbb7eff-a529-9590-31e7-b0007b416f81
Make leak counters implemented with SK_DECLARE_INST_COUNT thread-safe.
Enable the leak counting for Debug builds when Skia is built as a
static library. Having SK_DECLARE_INST_COUNT without
SK_DEFINE_INST_COUNT relies on static variables in member functions
declared in the header files. These might be duplicated in the clients
of the library when Skia is built as a dynamic library, producing
incorrect operation.
Protect the instance counter initialization step (initStep) by
using SkOnce.
Makes SkOnce.h part of the public API, since SkInstCnt is public.
Protect the per-class child list shared variable with a per-class mutex.
Changes the behavior in the way that if the child list has been
"cleaned up", it will still try to create subsequent child lists.
BUG=skia:1219
R=robertphillips@google.com, mtklein@google.com, bsalomon@google.com, bungeman@google.com, djsollen@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/99483003
git-svn-id: http://skia.googlecode.com/svn/trunk@13120 2bbb7eff-a529-9590-31e7-b0007b416f81
Skia cannot use Chromium's implementation of mutex (Lock) due to static
initializers. However, we would like to be able to use Chromium's
implementation of atomics. This motivates the split of implementation.
Skia's atomic and mutex calls should be inlinable, especially the atomics.
These calls often compile down to very few instructions, and we currently have
the overhead of a function call. This motivates the header implementation.
There is still a desire for the build system to select the implementation, so
the SK_XXX_PLATFORM_H pattern for header files is introduced. This allows the
build system to control which platform specific header files are chosen.
The Chromium side changes (most of which will need to go in before this change
can be found at https://codereview.chromium.org/19477005/ .
The Chromium side changes after this lands can be seen at
https://codereview.chromium.org/98073013 .
Review URL: https://codereview.chromium.org/19808007
git-svn-id: http://skia.googlecode.com/svn/trunk@12738 2bbb7eff-a529-9590-31e7-b0007b416f81
I'm working on some code that's much faster when compiled by GCC than by Clang
because GCC inlines more aggressively. Using SK_ATTRIBUTE(always_inline) on
the appropriate methods narrows the performance gap considerably.
This should work for MSVC, GCC, and Clang, otherwise falling back to "inline".
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/83333005
git-svn-id: http://skia.googlecode.com/svn/trunk@12364 2bbb7eff-a529-9590-31e7-b0007b416f81
