This serves two purposes.
First, we want to (some day) convert these messages into a less
obtrustive form, something like toaster notifications, such that they
don't interrupt workflow as harshly. That would, of course, be
nonblocking.
Second, some platforms, like Emscripten, do not support nested event
loops, and it's not possible to display a modal dialog on them
synchronously.
When making this commit, I've reviewed all Error() and Message()
calls to ensure that only some of the following is true for all
of them:
* The call is followed a break or return statement that exits
an UI entry point (e.g. an MenuX function);
* The call is followed by cleanup (in fact, in this case the new
behavior is better, since even with a synchronous modal dialog
we have to be reentrant);
* The message is an informational message only and nothing
unexpected will happen if the operation proceeds in background.
In general, all Error() calls already satisfied the above conditions,
although in some cases I changed control flow aroudn them to more
clearly show that. The Message() calls that didn't satisfy these
conditions were reworked into an asynchronous form.
There are three explicit RunModal() calls left that need to be
reworked into an async form.
We have a lot of classes with virtual functions but no virtual
destructor, mostly under render/. While this is not a problem
due to how our hierarchy is structured, some versions of clang
warn about this on the delete statement inside shared_ptr.
We could add a virtual destructor, but adding final qualifiers
expresses intent better, is generally more efficient (since it allows
devirtualizing most virtual calls in render/), and solves
the potential problem clang is warning us about.
We currently support MSVC 2013, and MSVC 2013 has weird bugs around
std::unique_ptr; the one we hit is Connect ID 858243. You can't
actually open the bug report anymore because Microsoft has shut down
Microsoft Connect. We probably shouldn't support a compiler so old
its bugtracker doesn't exist anymore, but there isn't any very good
reason to use unique_ptr for TimerRef either, so let's change that
for the time being.
This commit removes Platform::Window::Redraw function, and rewrites
its uses to run on timer events. Most UI toolkits have obscure issues
with recursive event handling loops, and Emscripten is purely event-
driven and cannot handle imperative redraws at all.
As a part of this change, the Platform::Timer::WindUp function
is split into three to make the interpretation of its argument
less magical. The new functions are RunAfter (a regular timeout,
setTimeout in browser terms), RunAfterNextFrame (an animation
request, requestAnimationFrame in browser terms), and
RunAfterProcessingEvents (a request to run something after all
events for the current frame are processed, used for coalescing
expensive operations in face of input event queues).
This commit changes two uses of Redraw(): the AnimateOnto() and
ScreenStepDimGo() functions. The latter was actually broken in that
on small sketches, it would run very quickly and not animate
the dimension change at all; this has been fixed.
While we're at it, get rid of unused Platform::Window::NativePtr
function as well.
This commit fixes two issues that cause issues in WebGL:
* Non-power-of-two textures must wrap as GL_CLAMP_TO_EDGE.
This breaks non-power-of-two textures.
* Render calls with zero primitives should not be issued.
This just causes warning spam.
The code in LoadStringFromGzip was attempting to perform an unaligned
access using memcpy, but it cast the source to a pointer with
alignment requirements larger than 1, which, under optimizations,
reintroduced the original issue.
This is to address MSVC warnings.
This commit changes a few configuration fields to use double instead
of float. There doesn't seem to be any reason these use float except
for the legacy Windows code using float for saved configuration.
Changing their type to double improves consistency.
This commit merges all ad-hoc file dialog code, such as the feature
where dialogs remember last location and format, and exposes it
through a common interface.
This commit also significantly improves Gtk dialog handling code.
This commit changes the awfully specific code for dialogs with
messages duplicated three times to go through a generic interface.
It also fixes some issues with the way translated messages
were parameterized.
This commit removes the custom message dialog box used on Windows,
for several reasons. First, it was the last element not respecting
HiDPI displays. Second, other OSes do not easily provide this much
control over rendering default message boxes, and both Gnome and
macOS frown upon non-standard renderings such as those; so the custom
rendering was already not used on the other OSes.
This commit mostly just changes the settings code to be in line with
the rest of the platform abstractions, although it also fixes some
settings names to be consistent with others, and uses native bool
types where applicable.
This commit also makes settings-related operations much less
wasteful, not that it should matter.
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.
We should make good use of in-place member initialization. Many
new classes have constructors that effectively do nothing but
default-initialize POD members, and when adding new members,
it is very easy to miss initializing them. With in-place
initialization, the code is more compact, the diffs are nicer,
and it's harder to miss them.
This commit only converts render/ and platform/ to use in-place
member initialization, since there was a bug in CairoRenderer,
but we should convert the entire codebase.
This changes the assertion failure behavior to be the same in debug
and release builds: to show the complete failure message, and
to offer to restart the application or defer to Windows Error
Reporting to generate a backtrace. Contrary to popular belief,
WER is not useless, and since SolveSpace publishes pdb files,
WER-generated reports can be symbolized.
This commit also addresses the long-standing problem where showing
a dialog on fatal error would re-enter the application code, thus
causing another error or a crash that is more fatal than the current
one.
According to the C standard all preprocessor definitions starting
with an underscore are reserved for standard and implementation use,
so don't use those. Also, sort and unique include directives.
windowBits of 16 means "decode gzip header" and "use window size
from zlib header". For some reason, this results in a window size
that is too small on OpenBSD. Instead, use maximum window size
explicitly, since there is no downside for doing so.
Since font sizes in SolveSpace are specified in terms of cap height,
we need U+0041 to determine cap height. Some fonts lack it; in
that case, we assume that cap height is the same as the size we've
requested. This avoids a crash, at the cost of completely wrong
(although consistent) metrics; I do not really know of a better way.
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.
To reproduce:
* New sketch;
* Create two redundant constraints, with second being automatically
marked as reference;
* Switch one of these to non-reference;
* Allow redundant constraints;
* All new constraints with labels created as reference, even
if that specific degree of freedom is not constrained yet.
Before this commit, if the source group of a step rotate/translate
group is forced to triangle mesh, the UI would show that the step
rotate/translate group is also forced to triangle mesh, but the group
would in fact contain NURBS surfaces.
glibc defines a CHAR_WIDTH macro in limits.h since about 6.3.*.
This is apparently added as a part of ISO TS 18661-1:2014, which
I cannot read because it is not publicly available, and which covers
some sort of floating-point extensions. This is one of those changes
that should never have been done yet here we are.
This commit updates a *lot* of rather questionable path handling
logic to be robust. Specifically:
* All path operations go through Platform::Path.
* All ad-hoc path handling functions are removed, together with
PATH_SEP. This removes code that was in platform-independent
parts, but had platform-dependent behavior.
* Group::linkFileRel is removed; only an absolute path is stored
in Group::linkFile. However, only Group::linkFileRel is saved,
with the relative path calculated on the fly, from the filename
passed into SaveToFile. This eliminates dependence on global
state, and makes it unnecessary to have separare code paths
for saved and not yet saved files.
* In a departure from previous practice, functions with
platform-independent code but platform-dependent behavior
are all grouped under platform/. This makes it easy to grep
for functions with platform-dependent behavior.
* Similarly, new (GUI-independent) code for all platforms is added
in the same platform.cpp file, guarded with #ifs. It turns out
that implementations for different platforms had a lot of shared
code that tended to go out of sync.
Extrustion top and bottom faces require a normal to be present.
Before this commit, the normal is always taken from the assembled
loop; if the loop could not be assembled (i.e. the loop is broken
or not coplanar) the normal will be (0,0,0), which breaks the sketch.
Also, loops are not generated when generating the sketch
to determine its bounding box.
This may result in spuriously broken sketches when e.g. undoing
a change that has broken a loop.
After this commit, loops are generated when generating for bounding
box, and if the loop could not be assembled, then the workplane
normal is used. This still results in failures when there is
no workplane, but those cases should be quite pathological.
Before this commit, a same orientation constraint created with
a workplane selected would only remove 2 of 3 DOFs. After
this commit, it properly removes all 3 DOFs.
Before this commit, lathe groups had three DOFs, which of course
could not actually move. After this commit, lathe groups have
zero DOFs, as expected.
This bug was introduced in commit 6dced80.
Before this commit, DoLater would be run as an idle callback,
which (depending on system performance) could either result in
a half-regenerated sketch being displayed, with only the dragged
entity updated, or no regeneration whatsoever during the drag.
After this commit, the GTK behavior matches macOS and Win32 ones.
Hiding the menu bar was only supported on macOS, and it is inherently
troublesome to port because keyboard accelerators on Win32 and GTK
are inherently dependent on the menu bar being visible.
On top of that, it's not clear how to bring it back if it's hidden
by accident.
Before this commit, when a point is constrained to an entity (point,
circle, arc of circle or line segment) by clicking on it,
the resulting constraint is not necessarily satisfied, and the next
regeneration may place the newly constrained point somewhere other
than the intended position. After this commit, the parameters
are modified to satisfy the constraint.
Commit f5485cb and its ancestors add a parameter to some constraints.
This parameter must be materialized and assigned a non-zero value via
ModifyToSatisfy for the solver library to not make unnecessary
changes to the sketch during the initial generation. For this, we
represent it explicitly instead of using hc.param(0), such that
the materialized constraint does not conflict with any user-defined
ones.
This commit follows 41365c5, which enabled export of Z coordinate
by using POLYLINE instead of LWPOLYLINE. After this commit, only
the AcDb2dPolyline/AcDb2dVertex are used when exporting flat views,
which may improve compatibility with 2d design packages.
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.
The somewhat confusingly named set_has_alpha() function does not
affect whether alpha can be used during rendering to the area.
Rather, it affects whether alpha will be used when composing
the contents of the area with the window underneath it.
Before this commit, if any rendering mode except "show all occluded"
is enabled, points can be highlighted for corresponding to a DOF
after "Analyze → Degrees of Freedom" but then promptly occluded,
which is confusing.
We want to suppress accelerators but still get input to (at least)
the window where the editor is opened. It's no harm to permit input
to other windows, but it is bad to route all of it to the editor,
since color chooser depends on being able to receive input.
So, what we do is add modal grab to the *overlay*, which has
the editor and the underlay widget, route all events as usual
to children, and just force the key events to go to the editor,
since otherwise they would still propagate up for some reason.
Before this commit, the first time NewFrame() is called,
the background color would not be filled, leading to interference
with whatever the GUI toolkit decided to put there.
This is a fairly standard CAD feature; it conveys the same
information and has the same recovery path, without erroring out,
so seems like an obvious win.
Before this commit, updates to the bitmap font in the graphics window
cause missing characters in the text window and vice versa. This is
because BitmapFont contains a texture that's mutated, and sharing it
would also require sharing display lists between GL contexts, which
is not done (and overly complicated for this case anyway).
Before this commit, dragging a new rect would result in one
of the lines lagging behind, because it is drawn in the middle
of regeneration. After this commit, the rectangle stays rectangular.
For a reason I do not understand, this only fixes Win32; GTK
continues to exhibit the bug, whereas Cocoa has never exhibited it
but the render latency seems to have lowered slightly.
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.
Before this commit, when an entity is clicked at or dragged, and it
shares a place with other entities, which of them is selected is
decided more or less at random. This is particularly annoying when
dragging.
After this commit, when clicking, an entity from the current group
is given preference, and when dragging, an entity from a request
is given preference. This allows e.g. dragging points of a sketch
even when an extrusion of that sketch is active.
Before this commit, it was possible to add some redundant constraints
(e.g. vertical, horizontal or midpoint) without failing the sketch,
because SolveBySubstitution() removed the redundant equations.
However, this could result in the solve failing later because
the system didn't converge, without any pointers as to the true
cause of the failure.
After this commit, any transparent triangles are drawn last, which
causes them to not clobber the depth buffer, and so if they overlap
some opaque triangles, then these opaque triangles will be visible.
There are still issues with overlapping transparent triangles,
and with transparent triangles overlapping outlines and entities.
It was broken because of three bugs:
* Uninitialized variables in RunCommand;
* Trying to use (OEM-encoded) main() argc/argv arguments instead
of GetCommandLineW();
* Trying to pass relative paths directly into ssfopen.
Before this commit, if constraints with newly introduced params were
loaded from a file that linked other files, the upgrade code would
attempt to look up a non-existent entity.
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.
Before this commit, inserting into BSP tree could easily overflow
the stack because we allocate very large stack frames and, on
convex geometries (e.g. a sphere), the BSP tree degenerates into
a "BSP list", thus requiring one large stack frame per triangle.
This can be reproduced by exporting a 2d shaded view of sphere.
After this commit, the stack frames only contan a pointer to
a supplementary data structure, and moreover it only allocates
its fields on demand, conserving heap memory as well.
As a side effect, an arbitrary classifier limit of 50 vertices
is removed.
This commit implements two improvements. First, it rewrites
SMesh::FirstIntersectionWith() to use an optimal (as currently known)
ray tracing algorithm. Second, it rejects triangles without
an associated face entity outright.
This partially reverts commit 3a585ea.
We no longer need this because the VectorsParallel() is gone, and
there is no chance of pivoting wrong when solving.
Before this commit, parallel constraints in 3d are fragile:
constraints that are geometrically fine can end up singular anyway
because VectorsParallel() pivots wrong but converges anyway.
After this commit, much like in cc07058, the constraints are written
in a different form: instead of trying to remove two degrees of
freedom out of three, all three are removed, and one added; namely,
the constraint introduces a free parameter, signed length ratio.
Before this commit, pt-on-line constraints are buggy. To reproduce,
extrude a circle, then add a datum point and constrain it to the
axis of the circle, then move it. The cylinder will collapse.
To quote Jonathan:
> On investigation, I (a) confirm that the problem is
> the unconstrained extrusion depth going to zero, and (b) retract
> my earlier statement blaming extrude and other similar non-entity
> parameter treatment for this problem; you can easily reproduce it
> with a point in 3d constrained to lie on any line whose length
> is free.
>
> PT_ON_LINE is written using VectorsParallel, for no obvious reason.
> Rewriting that constraint to work on two projected distances (using
> any two basis vectors perpendicular to the line) should fix that
> problem, since replacing the "point on line in 3d" constraint with
> two "point on line in 2d" constraints works. That still has
> the hairy ball problem of choosing the basis vectors, which you
> can't do with a continuous function; you'd need Vector::Normal()
> or equivalent.
>
> You could write three equations and make the constraint itself
> introduce one new parameter for t. I don't know how well that
> would work numerically, but it would avoid the hairy ball problem,
> perhaps elegant at the cost of speed.
Indeed, this commit implements the latter solution: it introduces
an additional free parameter. The point being coincident with
the start of the line corresponds to the parameter being zero, and
point being coincident with the end corresponds to one).
In effect, instead of constraining two of three degrees of freedom
(for which the equations do not exist because of the hairy ball
theorem), it constrains three and adds one more.
Before this commit, polylines got flattened but all other entities
got exported with the proper Z coordinate. After this commit, all
entities are exported with proper Z coordinate.
Also, instead of exporting LWPOLYLINE (2d only), POLYLINE (2d/3d)
is exported; as a bonus it is more compatible with 3rd party
software, since it is older.
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.
Before this commit, any visibility toggle would cause a regeneration.
After this commit, toggling visibility of normals and points never
causes a regeneration, and toggling visibility of edges and outlines
only causes a regeneration when they weren't already generated.
FromTransformationOf is called with an identity rotation or
translation for translation and rotation groups, and for every
group that doesn't produce a solid model. This commit omits any
calculations from it when the relevant part of transformation
would change nothing.
This commit results in a ~10% improvement on testcase
woodworking/big-big-big-woodworking-asm, and splitting the condition
into three parts results in a ~5% improvement on testcase
stress/rotate_groups_0.
SSurface::TriangulateInto first populates the mesh with triangles
that have no color, and then paints them, which confused the code
that detects if a mesh is transparent into thinking that all of them
are; and that broke the "draw back faces in red" feature, since it
is disabled for transparent meshes.
The configuration option "draw back faces in red" aids debugging,
in that it allows to visually identify a non-watertight mesh.
When it is disabled, or when the mesh is transparent, we used to not
draw them at all before this commit; after, they are drawn just like
the front faces.
This has two consequences:
1. Inner surfaces of non-watertight meshes are not see-through
anymore. That used to be the behavior in version 2.0, and it
was accidentally broken in 2.1.
2. Transparent meshes look *much* better.
3. Solids made from a union of a non-transparent and a transparent
one look sensibly at all.
This commit also updates the OpenGL 1 renderer to let it render
such meshes correctly.
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
This commit does three things:
* Recognizes that BeginFrame()/EndFrame() are badly named, since
BeginFrame() sets up framebuffer, and EndFrame() flushes a frame,
and they do not have to be called in pairs; and so renames them
to NewFrame()/FlushFrame().
* Reduces the amount of frame flushes in GraphicsWindow::Paint()
to two, which is the minimum since we use two different cameras
for geometry and UI;
* Changes the FPS measurement code to only take into account
the time spent rendering our main geometry, and not the UI
rendering or window system interaction time.
Before this commit, tooltips in the text window are drawn under
the red "X" indicating a disabled button. After this commit, they
are moved on top of that.
This commit also alters the OpenGL renderers' SetCamera() method
to clear the depth buffer, as that would interfere with drawing
the UI; the toolbar would get occluded by geometry.
To actually achieve improved performance with the OpenGL 2 renderer,
we have to cache geometry that doesn't change when the viewport does
(note that the rendered pixels can change quite dramatically because
we can reconfigure shaders; e.g. stippling can be drawn in screen
coordinates).
This commit adds a BatchCanvas interface that can be implemented
by renderers, and uses it for drawing entities such as lines and
points.
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.
OpenGL 2 and newer do not have the glPolygonMode(..., GL_LINES) API,
so produce the wireframe on our side. It's somewhat slow, and draws
every line three times, but it is cached when the OpenGL 2 renderer
is used, and this should do for a debugging feature.
whitequark
Alexander Meißner
Bauke Conijn
Guido
EvilSpirit
Mat M
luzpaz
Elvira Khabirova