This is unfortunate, but OpenMP is not available on some toolchains
(most MinGW builds) and, more importantly, breaks the distribution
model we use on Windows, which is a single self-contained executable.
Leave the OpenMP disabled by default everywhere so that we don't have
any second-class platforms where SolveSpace is slower than on first-
class ones.
Fixes#631.
The counter was added solely as a debug feature in commit e7c8c1c8,
which introduced the new Canvas system. It doesn't work all that well
and brings little value, so let's get rid of the visual noise.
This commit continues the work started in commits 521473ee and
e84fd464 that parallelizes certain geometric operations. This commit
cleans up the temporary arena implementations and makes them
thread-safe.
Also, in commit 521473ee, a call to FreeAllTemporary() was added
during initialization to create the heap on Windows. This is now
not necessary as the heap is created transparently on the first call
to AllocTemporary().
When checking the dot product of the tangents `tu` and `tv` to decide
in which direction to split a quad compare it to to LENGTH_EPS instead
of zero to avoid alternating triangle "orientations" when the tangents
are orthogonal (revolve, lathe etc.).
This improves the quality of the resulting triangle mesh.
Commit ea6db67 added an unusual isnan macro:
#define isnan(x) (((x) != (x)) || (x > 1e11) || (x < -1e11))
Commit 8bc322e adds a preprocessor guard that looks like it would
cause the isnan function from math.h to be preferred, but doesn't
actually do that on many platforms, e.g. glibc:
#ifndef isnan
# define isnan(x) (((x) != (x)) || (x > 1e11) || (x < -1e11))
#endif
This commit renames our isnan() to make it clear that it differs
from the standard library operation, and makes it a function.
Fixes#603.
We use std::fabs, but <math.h> doesn't provide it; it worked by accident.
Include <cmath> that provides std::fabs, and switch all other headers to
their C++ variants, too.
VS2013 does not have constexpr support and in general is quite buggy.
There's no reason to use it anymore as even XP toolsets are available
for VS2015 and VS2017.
* Don't use a reserved identifier in include guards.
* Use fabs() from <cmath> instead of our own ffabs().
This shouldn't make any difference with modern toolchains.
* Convert a few preprocessor macros to constexprs.
After this commit, dbp() is renamed to DebugPrint() and moved to
platform.cpp, next to other similar functions. The existing short
name is provided by a preprocessor macro, similar to ssassert().
This leaves just the (rather hacky) temporary heap in util*.cpp.
This commit performs three related cleanups:
* The slvs library no longer uses explicit platform initialization
(which drags in the side effects of InitPlatform that are not
desirable in a library). Instead, it just ensures that it has
the temporary heap, which is what it was callingInitPlatform for.
* InitPlatform is simplified and moved to platform.cpp, next to
other path related functions.
* InitPlatform is renamed to InitCli and is called from InitGui
implementations. GUI toolkits sometimes have options they use
internally (that's the case for for GTK and Cocoa at least),
and we shouldn't try to parse those as a file to open.
Historically SolveSpace used its own heap on Windows since it gave
better control and debugging options, but a lot of development these
days happens on Linux, where that heap was a stub around malloc/free,
and also Windows debugging tools got a lot better.
In terms of immediate benefit, this commit fixes heap corruption
on Windows introduced in commits b4e1ce44 and 47e82798, caused
by allocating with HEAP_NO_SERIALIZE in parallel from OpenMP threads.
Without HEAP_NO_SERIALIZE there's no performance benefit to keeping
our own heap, either.
The vl() function is also removed because for development there are
better tools now, and the only place where it was permanently called
from became a no-op, since temporary heap always validates after
FreeAllTemporary() recreates it.
arm64 builds on Travis are not yet fully mature and this
causes a high failure rate that is not caused by our code.
Continue building and deploying arm64 to the edge channel,
but don't consider the result for the success of the whole
build job.
Alleviates #587
whitequark
phkahler
ruevs
Maximilian Federle