Apitrace uses swapping buffers to determine frame boundaries; before
this commit, everything solvespace renders gets put into a single
frame. Since we don't use double-buffered rendering, the call does
nothing (and is legal to perform), but apitrace output becomes
readable.
Sometimes, after a large change in a sketch, constraints that are
geometrically fine may still cause the rank test to fail. One way
this can happen is VectorsParallel() pivoting wrong due to the big
move, converging anyways but ending up singular. It would then
re-pivot correctly on the new solution when you re-solve, making
this a transient error. This is visible when dragging the arm in
the jansen-asm.slvs example.
After this commit, if the rank test fails, equations are regenerated
the Jacobian is rewritten, and the rank test is retried, which
prevents these transient errors from interfering with dragging.
The problem described above was invisible before c011444, as rank
test was only performed before solving.
A system solved as REDUNDANT_OKAY is still solved correctly,
even if the UI would consider this an error, in case that
g->allowRedundant==false. So there's no reason to discard this
solution; we might find it useful if a system loses a degree of
freedom while dragging, or to avoid regeneration after redundant
constraints are allowed.
This commit also reverts commit 3ff236c, as that is not necessary
anymore.
Before this commit, the outlines are generated in an arbitrary order
from the kd-tree. This worked just fine for continuous lines, but
for stippling, especially on curves, this meant that most of
the piecewise linear edges would have the stippling phase restart
from zero, leading to a very poor appearance.
These were useful before because chord tolerance depended on the zoom
level; and so the first generation produced a crude mesh used to
set the zoom level, and the second actually did useful work.
Chord tolerance is now independent of the zoom level, so this code
is no longer useful.
Before this commit, a translate group based on another translate
group would always use the "union" boolean operation, which does not
work at all if one wants an array with a difference operation, and
results in degraded performance if one wants an array with
an assemble operation.
This significantly improves performance e.g. in case of a sketch
containing a multitude of wooden panels, as the meshes can be
merely transformed instead of being joined.
The check was actually half-broken from the beginning and
until df83ee4; the thick red line was rendered properly but
the error text was rendered with width 0, which by chance worked
on some GL implementations. That commit has fixed the underlying
bug but left the text line width at 0 to avoid test breakage.
This commit fixes the bug, turns off the check completely, and
updates the tests to account for breakage.
The libspnav library doesn't even define SI_APP_FIT_BUTTON, which
appears to be Windows-specific functionality, perhaps a physical
button remapped with some logic. Just use 0 instead, since that
seems always safe.
