I’ve frozen OpenSCAD so many times in the last few days, testing various attempts at fixing my hideous problem, that I’m starting to see patterns. I managed to work on it for several hours last night with only occasional freezes, and no crashes of the windows mouse driver software. So I’ll hesitantly say that OpenSCAD is usable for me again if I’m really gentle and patient.
I do my editing in a separate text editor (Crimson – which I’ve set up with a degree of OpenSCAD-aware syntax highlighting) so if OpenSCAD does die completely I’ve still got my code in another location).
My current standard operating procedure is to ensure I always wait for at least a second between releasing a mouse button, and clicking it (or a different button) again. It’s like stroking a nervous kitten. You’ll be amazed at how that goes against years of GUI operating experience…
The freezing most often happens if I click a mouse button again too soon after the last time I tried to move or rotate the render display. This has happened with the internal laptop buttons, two different usb mice, and a wacom usb graphics tablet.
The most reliably reproduceable freeze is to drag and wiggle the display with the left button, then while still doing that click and hold the right button too. And yes, I know there’s no real good reason why you’d want to perform that sequence of mouse operations – but it still shouldn’t kill the graphics system! No application should be able to do what’s happening here.
It’s like it takes a moment or two for OpenSCAD to recover from the last batch of 3D render instructions to the OpenCSG libraries (or whatever they are), and if you send another commmand while the previous is still being dealt with, the rendering system crashes. Maybe on a really fast computer (which I don’t have), this wouldn’t happen.
I’m guessing an error return code is being ignored at some point (possibly deep in a library), and a program is busy-waiting for a response. I’m on a middle-of-the-road 4-core laptop, and as soon as the screen-freeze happens the processor usage on one core goes to max and stays there, bouncing up and down slightly, until ctrl-alt-delete breaks the deadlock. Then OpenSCAD acts upon all the waiting mouse events as if nothing had happened.
And another, maybe unrelated thing. When I do an OpenSCAD CSG tree dump, there are several coordinates, usually part of a triplet where the other two coordinates are zero, with values like -1.83697e-16 Now I’m no great shakes as a mathematician, but it seems to me that a floating point number that close to zero is going to cause problems for the maths libraries at some point. Anything you divide by that number will become huge (or infinite if rounding bites you), and anything you multiply by it will become tiny.
I certainly didn’t use any values like that in my code for my objects. I wonder if that observation might be helpful to the developers, or if I’m just starting at shadows.