leorat has quit [Remote host closed the connection]
leorat has joined #solvespace
<swivel>
it'd be nice if solvespace were always interruptible with ESC or something... as my assemblies become large and complicated things get quite slow, and sometimes just accidentally clicking something sends it off into la-la land for a long time that isn't even a desirable operation that will just be undone once it's responsive again
<whitequark>
swivel: it used to be
<whitequark>
unfortunately, the precise way in which that was implemented was tied deeply into the implementation details of an OpenGL 1 based Win32 GUI
<whitequark>
I had to tear it out when making solvespace crossplatform and it's really not trivial to bring that capability back (on the other OSes mostly, but on Windows too, with the new rendering code)
<swivel>
I don't get the impression that it's during rendering that my long delays I wish were interruptible occur, so I'd expect something satisfactory to be possible while still treating the rendering stage as an uninterruptible atomic thing
<swivel>
i assume it's the solver doing stuff, since once it's finally finished i can once again rotate and zoom and navigate the 3d stuff at full speed
<whitequark>
you're correct; I'm not being very clear
<whitequark>
the bottom line is that SolveSpace computes everything in the message loop
<whitequark>
this presents many problems; on GTK you can sorta poll the message loop but it's quite hazardous, on macOS I believe you can't, on Win32 it's of course trivial
<whitequark>
though also subject to the same race condition hazards
<whitequark>
regarding rendering: I misremembered
<whitequark>
what it had is a *progress bar* that would roughly show you the progress of the solver
<whitequark>
this relied on BeginPaint/EndPaint, which is just not a thing in either GTK or macOS
<whitequark>
besides the fact that we don't use immediate mode rendering anymore
<swivel>
i see, yeah that's unrelated to cancellation
<whitequark>
yeah, it's related to long operations but not cancellation in particular
<whitequark>
I suspect it is possible to hack something together that'd work on Win32 and GTK but... it'd be difficult
<swivel>
i figured every platform would have some way of polling for new events if the solver could just occasionally do a "is cancelled" callback
<whitequark>
let me refresh my memory
<whitequark>
ah yes. on Win32 you have PeekMessage, which actually lets you just check if there's a pending Esc keypress
<swivel>
like I just accidentally clicked the extrude button in the toolbox on a huge complicated assembly, when I intended to click the nearest isometric view button :)
<whitequark>
(I wonder why this wasn't used in the original Win32-only version?)
<whitequark>
GTK doesn't let you filter the message queue.
<whitequark>
what it does let you do is:
<whitequark>
while (gtk_events_pending ()) gtk_main_iteration ();
<whitequark>
but ... you can't just do that, because SolveSpace's codebase is not reentrant
<whitequark>
and at the same time it's exclusively event driven
<swivel>
nod, you don't want to run the full gui event loop, just escape handling
<whitequark>
no way to do this afaik
<whitequark>
you can get the current event, but that's not really useful
<whitequark>
I know a really hacky way to do this
<whitequark>
basically, set a global flag that freezes all event processing (essentially ignoring events) when you re-enter the event loop
<whitequark>
except for Esc
<whitequark>
so that's really horrible but i think it should work reliably for the most part
<whitequark>
the real problem is macOS
<swivel>
would that just discard all the non-esc events during that period?
<whitequark>
sure
<whitequark>
i mean, do you want all of them to arrive once it unfreezes?
<whitequark>
that seems like it'd be a good way to mess up your sketch
<swivel>
well, events are a generalized mechanism no? isn't there a bunch of other stuff that could be important?
<whitequark>
maybe... and we can't do anything about any of it
<swivel>
like the WM sending crap
<whitequark>
oh
<whitequark>
those are handled transparently by GTK
<whitequark>
i'm just talking about the events that actually arrive to our widgets
<swivel>
i see
<whitequark>
it'd be a bunch of conditionals in GtkWindowImpl
<swivel>
so what's the trouble with MacOS?
<whitequark>
ok, i was wrong
<whitequark>
[NSApp nextEventMatchingMask:
<whitequark>
does pretty much what we want
<whitequark>
think you can open an issue summarizing this?
<whitequark>
oh, there's also the question of what happens when you interrupt an operation
<whitequark>
do we leave the sketch is an inconsistent state? do we undo? i'm leaning towards the latter
<swivel>
it should undo whatever was done returning to it's pre-cancelled-operation state
<swivel>
i can file an issue
<whitequark>
great! i'll try to find some time to implement it
<whitequark>
seems like very nice quality of life improvement
<_whitenotifier-3>
[solvespace] vcaputo opened issue #686: [RFE] Support cancellation of slow operations - https://git.io/JUkrA
<swivel>
it would be neat if when cancelled it didn't restore *everything* but maybe that's complicated
<swivel>
like there are cosmetic things which for some reason occasionally seem to trigger the solver
<swivel>
maybe that's a different problem
<whitequark>
not restoring everything is probably a lost cause
<swivel>
nod, i feel like it was a misguided out-loud thought ;)
<swivel>
maybe there could just be a secret key one can hold down to defer running the solver
<whitequark>
:S
<swivel>
like "hold on let me click a bunch of cosmetic things before you run off and do that"
<swivel>
like clicking on the draw occluded lines thingy
<swivel>
why is that slow?
<_whitenotifier-3>
[solvespace] whitequark commented on issue #686: [RFE] Support cancellation of slow operations - https://git.io/JUkoq
<swivel>
maybe the argument is just stop entering the solver unnecessarily
<whitequark>
oh
<whitequark>
it doesn't enter the solver
<whitequark>
it recomputes the display geometry
<whitequark>
by the way, that's a heavily optimized version we spent probably months working on
<whitequark>
:s
<swivel>
hahah
<whitequark>
it caches everything it can cache
<swivel>
I'm probably using solvespace for things it's not intended to, modeling architectural drawings for cabins and roofs etc
<whitequark>
it's ... well
<whitequark>
we (with Aleksey) were pushing it in that direction
<whitequark>
it works a *lot* better than it used to, for this kind of application
<whitequark>
but it's just a really challenging legacy codebase
<swivel>
it's pretty close to capable of this work
<swivel>
but pretty frustrating because it's at that boundary where it's good enough to try get serious with it, and runs into a performance wall every time I reach the complexity of something along the lines of a complete cabin with framed walls and roof in a single assembly
<whitequark>
are you using the "assembly" method of combining solid model?
<whitequark>
i assume you do but just checking
<swivel>
i think so?
<whitequark>
have you tried building with OpenMP?
<swivel>
nope
<swivel>
should I?
<whitequark>
try it
<whitequark>
it might get, I dunno, twice as fast?
<whitequark>
would that help? :p
<swivel>
twice as fast would be incredible
<whitequark>
try it
<whitequark>
it'll do nothing for the solver, but geometry operations will proceed in parallel some of the time
<whitequark>
speaking of the solver... I should integrate the PR that adds Eigen
<whitequark>
I'm pretty sure that will solve many of your woes
<whitequark>
ping me every weekend so I don't forget :p
<swivel>
hahah I'll try
<swivel>
I don't see mention of openmp in the readme, do I just add -DENABLE_OPENMP to the cmake commandline?
<whitequark>
openmp support is unofficial
<whitequark>
the problem is that on win32, there is no statically linked openmp
<whitequark>
which totally breaks solvespace's distribution model there
<whitequark>
the best thing i can do is to unpack, drop, and load a DLL from within the executable, but i bet that will raise alarms for every AV in existence
<swivel>
so what's the magic incantation to get the openmp build? it looked like I have libgomp installed here
<whitequark>
moment
<whitequark>
yeah -DENABLE_OPENMP=ON
<swivel>
ah =ON
<swivel>
maybe I can make /usr/local/bin/solvespace more crashy too :)
<swivel>
hm i don't think it's any faster
<swivel>
slower even, oh well :)
<swivel>
maybe my debian libgomp1 isn't optimized for my cpu
<whitequark>
huh, odd
<whitequark>
libgomp is just a scheduler
<swivel>
w/OPENMP:
<swivel>
Generate::DIRTY (for bounding box) took 2864 ms
<swivel>
Generate::DIRTY took 5816 ms
<swivel>
without:
<swivel>
Generate::DIRTY (for bounding box) took 2547 ms
<swivel>
Generate::DIRTY took 5136 ms
<whitequark>
super odd
<whitequark>
maybe open an issue and tag @phkahler if you can show him the .slvs?
leorat has quit [Remote host closed the connection]
leorat has joined #solvespace
<swivel>
it's kind of a big sprawling mess of .slvs files now, but i can probably make a simpler reproduction of this in a single .slvs
<swivel>
is there a function for consolidating everything into a single .slvs export?
<whitequark>
no; there are some plans in far future
<swivel>
cuz the way i work is i have things like WxHxL.slvs for individual pieces of wood like studs etc, then i link those into an assembly using lots of step+repeat and rotate stuff, save that into something like frame.slvs, then that gets linked into a structure.slvs with all the framed walls, then that gets linked into another house.slvs with the roof on it etc.
<swivel>
is that the appropriate way to use solvespace? or am perhaps is that part of why my perf. turns rotten?
<swivel>
s/am perhaps/perhaps/
<whitequark>
no, that's pretty reasonable
<whitequark>
quite possibly even optimal
<swivel>
well, it's a comfortable workflow for my programmer mind
<swivel>
i just wish it didn't become unusably slow as the assembly grows because it's really limiting how much of my project i can model at once
<swivel>
maybe i need a faster cpu
<whitequark>
it's possible, likely even, things can be improved
<whitequark>
unfortunately i don't have time right now for a deep dive into a profiler
<swivel>
nod, i understand, hugely appreciative of what solvespace already provides - it's kind of amazing
<whitequark>
a lot of it is due to the original author, Jonathan Westhues
<whitequark>
most, probably :)
<swivel>
where's jonathan nowadays?
<whitequark>
no idea
<whitequark>
we only really discuss technical topics, and even then rarely
<swivel>
FWIW just looking at the top offenders of a `perf record /usr/local/bin/solvespace bigassembly.slvs` simply loading and quitting once it manages to draw the view:
<swivel>
maybe this is a unique to startup overhead?
<whitequark>
hm
<whitequark>
try collecting more data
<swivel>
hm nope, switched to valgrind so I've got some call chains too, I zeroed the counters before trying to add a line segment to the big assembly and dumped once it finally occurred
<swivel>
std::_Temporary_buffer is the big one
<whitequark>
okay, then idlist indexing might help
<swivel>
it sounds like it's not even the solver then
<whitequark>
yeah i'm quite certain that improving idlist would help
<whitequark>
unfortunately it's... tricky
<whitequark>
but definitely doable
<swivel>
is this basically just list operations overhead?
<whitequark>
more or les
* swivel
fetches Evil-Spirits branches
<swivel>
hmm i don't see id-list-indexing, is that not a branch?
<swivel>
oh, wrong repo!
* swivel
crosses fingers
<swivel>
certainly more compilation warnings on this tree
<swivel>
wow
<swivel>
ok that loaded instantly
<whitequark>
yup. quadratic.
<swivel>
oh man! toggling the occluded lines is instantaneous
<whitequark>
ohh
<swivel>
ok this is totally fixed
<whitequark>
ohhhhhhhh right it regenerates the entities on one of the codepaths for that button
<whitequark>
not just geometry
<swivel>
adding a line segment just happens now, even wit hthe full assembly
<whitequark>
huh impressive, you've really hit the most pathological possible case
<swivel>
whitequark: so why not land evil-spirit's changes?
<whitequark>
we should
<swivel>
is there something wrong with the code?
<swivel>
just two smallish commits
<whitequark>
not really; I think at the time I was undecided between using that and going with some STL container, but now I know that evil-spirit's solution is more appropriate
<whitequark>
it just doesn't apply on top of master anymore
<swivel>
this is amazing, I'm liable to stay up all night making the most complicated models I've literally ever been able to do, probably by orders of magnitude
<whitequark>
huh
<whitequark>
yeah let's merge that soon
<whitequark>
i didn't realize the true speedup of that patch
* swivel
digs up the old heat exchanger model where he modeled the individual channels of coroplast that started taking minutes to manipulate before giving up on it
<swivel>
well, that was looking promising
<swivel>
but when I attempted to actually make progress from where that thing left off: