It was added in 3a3a2755b as a potential way to export colorful meshes
to Horizon EDA but ended up being supported only by SolveSpace. Since no
software can consume the exported q3do files the feature is superfluous.
See https://github.com/solvespace/solvespace/issues/795 for details.
This reverts commit 68b1abf77f.
The warnings are valuable and shouldn't be cast aside.
As of 8f509f1, we special case macOS and don't set -fno-sanitize-recover
to allow CI to succeed.
In the future, this could be made stricter again by only suppressing
known bugs, which ideally should also be fixed or reported upstream.
Previously sanitizer flags were set unconditionally for
all code, including that of external libraries.
Set them only for targets in src/, tests/ and exposed/.
Unfortunately, the linker equivalent to add_compile_options,
add_link_options, is only available for CMake version >= 3.13.
So add the sanitizer flags manually to each target's linker options.
This has been completely broken since 2018 (commit a93283df), and no
one noticed, so it probably wasn't useful. Instead of fixing it, just
drop the feature and a bunch of odd nonportable code.
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().
See:
https://github.com/solvespace/solvespace/issues/92#issuecomment-567831112
The problem was first introduced here:
dabd57847e
and later "fixed" here:
f324477dd0
by setting the stack size to /STACK:33554432
Solvespace now starts up even with /STACK:554432
According to this:
https://en.cppreference.com/w/cpp/language/value_initialization
```
"2) if T is a class type with a default constructor that is neither user-provided nor deleted (that is, it may be a class with an implicitly-defined or defaulted default constructor), the object is zero-initialized and then it is default-initialized if it has a non-trivial default constructor; "
```
So removing the `{}` should leave both the `System` and `TextWindow` class instances properly initialized.
We plan to use flatbuffers in the future for the next generation of
the .slvs file format, so flatbuffers are built unconditionally; and
the Q3DO exporter itself is tiny.
This commit removes a large amount of code partially duplicated
between the text and the graphics windows, and opens the path to
having more than one model window on screen at any given time,
as well as simplifies platform work.
This commit also adds complete support for High-DPI device pixel
ratio. It adds support for font scale factor (a fractional factor
on top of integral device pixel ratio) on the platform side, but not
on the application side.
This commit also adds error checking to all Windows API calls
(within the abstracted code) and fixes a significant number of
misuses and non-future-proof uses of Windows API.
This commit also makes uses of Windows API idiomatic, e.g. using
the built-in vertical scroll bar, native tooltips, control
subclassing instead of hooks in the global dispatch loop, and so on.
It reinstates tooltip support and removes menu-related hacks.
This commit removes a large amount of redundant code that needed
to be kept in sync between platforms and also makes it much easier
to add new menu-related functionality since little to no platform
code needs to be altered anymore.
This commit also greatly improves code locality in context menu
handling by allowing context menu click handlers to be closures.
This commit temporarily introduces a SetMainMenu API, which is rather
hacky but only necessary until an abstraction for windows is added.
There was a copy rule that copied the locale from the source
to the binary directory, and also a regeneration rule that used
the locale in the binary directory as a temporary file.
Rename the target for the latter.
The existing code is horrible and needlessly platform-dependent.
Even worse, it causes a freeze on GTK. Instead of propping that up
with a few more crutches, just fix the root cause.
It's a deprecated platform that has weird OpenGL-related bugs and
is incompatible with using EGL anyway. It was clear we're going
to drop it, the only question was when. Answer: now.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
The only thing we need it anymore is the package version and platform
configuration, so only include it for that. As a result, less files
are rebuilt when the git commit changes and config.h is regenerated.
This commit performs two main changes:
* Alters the shaders to use only strictly conformant GLSL 2.0.
* Alters the Windows UI to use ANGLE via GL ES 2.0 and EGL 1.4.
This commit also drops official support for Windows XP, since ANGLE
requires a non-XP toolset to build. It is still possible to build
SolveSpace for Windows XP using:
cmake -T v120_xp -DOPENGL=1
There are two main reasons to desire an OpenGL 2 renderer:
1. Compatibility. The compatibility profile, ironically, does not
offer a lot of compatibility, and our OpenGL 1 renderer will not
run on Android, iOS, or WebGL.
2. Performance. The immediate mode does not scale, and in fact
becomes very slow with only a moderate amount of lines on screen,
and only a somewhat large amount of triangles.
This commit implements a basic OpenGL 2 renderer that uses only
features from the (OpenGL 3.2) core profile. It is not yet faster
than the OpenGL 1 renderer, primarily because it uses a lot of small
draw calls.
This commit uses OpenGL 2 on Linux and Mac OS X directly (i.e. links
to the GL symbols from version 2+); on Windows this is impossible
with the default drivers, so for now OpenGL 1 is still used there.
Abstract the exact details of the OpenGL renderer in the render.h
header; this allows us to use GL-specific types in the renderer
class and functions without including OpenGL (and Windows, where
applicable) headers in every source file.
