There are 'hotkey' utilities out there that can intercept keystrokes and do
what you want.
For Windows I use  autohothey https://www.autohotkey.com/  .

Are you sure you want to render?

Are you sure you meant to say yes? (type YES to confirm)

Render cancelled

Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

View this message in context: http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20487.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Well, this is what I think.

I really don't want the program to ask me if I really want to do something.
This annoys me.
BUT, I don't think the cancel render button (the x) works at all.
If we fix that, then all would be well.

I know from my old programming days, if you do some really cpu intensive
calculations, that if you don't check for the presence of a cancel variable
once in a while, then there is no way it can be cancelled. So, what would
be needed is to check every nook and cranny of the render code, to see
where it would be necessary to check that cancel variable and do the right
thing.

Jerry

--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov

On Sat, Feb 18, 2017 at 9:47 PM, MichaelAtOz oz.at.michael@gmail.com
wrote:

Adding cancel points to CGAL would require making a private copy of CGAL
,hacking it, then reapplying those hacks when new releases of CGAL come
out. It's a big complex library. I'm assuming we don't do that now, and it
seems undesirable.

We could also do the rendering in a separate thread, and abandon that
thread if cancel is pressed. That seems more achievable.

On 19 February 2017 at 19:29, Jerry Davis jdawgaz@gmail.com wrote:

Jerry:

I thought he wanted an OPTION to add this feature/question.  If the rest
of us can turn the option off, I don't see what is wrong with his
suggestion.

Jon

On 2/19/2017 7:29 PM, Jerry Davis wrote:

Jon:

I didn't see that. Ok. Option ok. Turn it off by default ok.

Doug:

Didn't know OpenSCAD used a separate lib for CGAL. Separate thread that is
cancellable is better.

--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov

On Sun, Feb 19, 2017 at 7:12 PM, adrian adrianh.bsc@gmail.com wrote:

On Sun, Feb 19, 2017 at 07:38:16PM -0500, doug moen wrote:

This strongly depends on how the library works. If you call it adding
objects and that at the end you call "now_render_it ()" then your
argument holds.

But if WE maintain the upper level loop that implements the time
consuming work, then of course we can step out of that loop easily
when cancel is pressed.

But this is of cousr something that can always be done. (.... at least
once: if you abort a rendering, I'm not sure the internal state is clean
enough to ever be able to restart it again....)

Roger. 

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Rogier: yes, that's it. I now remember a discussion by the dev team about
how CGAL is not thread safe. It is something they are working on. There is
also an open CGAL bug to add callbacks to better support progress bars.

My understanding is that we have a cancel operation, but cancellation is
deferred while executing a CGAL CSG operation, which can take hours. And
that's hard to fix given CGALs limitations, especially lack of thread
safety.

On Monday, 20 February 2017, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

We already perform rendering in a separate thread: https://github.com/openscad/openscad/blob/master/src/cgalworker.cc

While we can abandon this thread, it would still continue to use resources and block any other CGAL operation until the thread ends. I’m not too excited about that idea.

I’m not aware of any safe way to kill a thread, but that could be a worthwhile investigation.

-Marius

I've investigated ways to safely kill a thread. One theoretical way I found
(for pre-emptive thread cancellation) is gcc specific, requires compiling
all libraries with special experimental codegen flags, probably requires
additional magic, not worth discussing. A more feasible way is cooperative
thread cancelation where the code you want to interrupt periodically checks
a global or thread-local 'cancellation' variable: this requires changes to
CGAL which are at least partially in progress. Maybe this support finally
arrives, but then you want to replace CGAL with a faster rendering library
with the same problem: then what? Or you could run CGAL in a separate
process, and kill the process if cancelled by the GUI process.

On 20 February 2017 at 14:58, Marius Kintel marius@kintel.net wrote:

On 20. feb. 2017 20:58, Marius Kintel wrote:

I don't know about Qt threads but I have done this with wxWidgets and
boost::threads

One way is to establish a thread safe queue and send messages to the
thread that way (the thread will check the queue). Or 'simply' a mutex
protected variable as was suggested. A third way is to send a message
(wxWidgets has wxThreadEvent, perhaps Qt has something similar... looks
like it https://wiki.qt.io/Threads_Events_QObjects )

Using such techniques it works for any OS or compiler.

Carsten Arnholm

How does that help with a thread that blocks for hours in a library that
you don't control? You either have to kill it asynchronously or wait for it.

On 20 February 2017 at 21:41, Carsten Arnholm arnholm@arnholm.org wrote:

On 2017-02-21 01:36, nop head wrote:

If it really blocks for hours without any chance of graceful
termination, I would review the architecture, library or how it is used.
Usually there is a way, e.g. using callbacks, deriving from the thread
class or whatever. Another option is to run lengthy jobs in a separate
process. That is in fact what I do with similar code, and if you
really have to it is easy to kill such processes and I do it
sometimes. The way I understand it, such a setup in OpenSCAD would
require a modified architecture though.

Carsten Arnholm

A multi-process architecture, with rendering in a separate process, is
probably a good solution. It's not just to support "cancel", it is also for
robustness: if the renderer crashes, you don't lose your state. This is how
modern web browsers now work.

On 21 February 2017 at 03:54, arnholm@arnholm.org wrote:

As long as we use CGAL, I think I agree that a separate process is a good way forward. This could also prove to be a way of bypassing the lack of multi-threading in CGAL, at the expense of managing the worker pool, dealing with (de-)serializing and optimizing potential local caching in worker processes.

The question is, as always, if we’re better off spending that time working on alternative CSG engines.

-Marius

And not only for cancel and robustness. Worker processes are also a good
means for parallelizing CGAL calls and speeding up things dramatically on a
contemporary machine. My approach for implementing this would be: Drop the
implicite union of toplevel objects (or add some option for it) and you are
on the way. After rendering top level objects could be checked first by
boundary tests, second by convex hull overlap and third by further CGAL
calls for possible mutual intersection - with most of this work already
being done, while the last CGAL worker process is still running.

kintel wrote

--
View this message in context: http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20538.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Or a separate thread to save the work (like the Arduino IDE, the "Save"
button always works no matter is or is not going on).

Rob

On 20/02/17 15:39, Jerry Davis wrote:

--

Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/

On 4 March 2017 at 15:23, dnivoG dnivogamrahs@gmail.com wrote:

I also intent to raise the same query. It is crucial from our point of
view as we are kind of stuck at this point.

--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor

"The journey of a thousand commit begins with a single init"

On 15 March 2017 at 10:22, MichaelAtOz oz.at.michael@gmail.com wrote:

https://github.com/openscad/openscad/blob/4af51a7443e5f6e8fb234beadc8128261854ae68/src/mainwin.cc#L764

Thanks.

Like in case of CSG, we have also used the node.progress_report() function
in GeometryEvaluator::visit (
https://github.com/openscad/openscad/blob/master/src/GeometryEvaluator.cc#L524
) function that essentially raises the exception upon the press of the
cancel button.

--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor

"The journey of a thousand commit begins with a single init"

--

Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor

"The journey of a thousand commit begins with a single init"