Empathy List Archives

PK

Peter Kriens

Tue, Sep 10, 2024 7:53 AM

The rendering process cannot be canceled and the GUI is unresponsive. I see discussions of this on

https://github.com/openscad/openscad/issues/1195
https://github.com/openscad/openscad/issues/1901

However, it is discussed to run the rendering in a separate thread. In another project, we had a similar problem with libraries that are not well behaved in a multi threaded environment and even could crash. (I have a OpenSCAD library that hangs the process when it gets wrong data.) We ran those programs in another process, perfect isolation. You can easily kill that process when the result is no longer needed.

Nowadays, starting a process and getting the result is lightingly fast and the amount of time spent on this part is dwarfed by the rendering time.

It is generally easy to do and I think Openscad can already be used as a command line application?

Regards,

Peter

The rendering process cannot be canceled and the GUI is unresponsive. I see discussions of this on https://github.com/openscad/openscad/issues/1195 https://github.com/openscad/openscad/issues/1901 However, it is discussed to run the rendering in a separate thread. In another project, we had a similar problem with libraries that are not well behaved in a multi threaded environment and even could crash. (I have a OpenSCAD library that hangs the process when it gets wrong data.) We ran those programs in another process, perfect isolation. You can easily kill that process when the result is no longer needed. Nowadays, starting a process and getting the result is lightingly fast and the amount of time spent on this part is dwarfed by the rendering time. It is generally easy to do and I think Openscad can already be used as a command line application? Regards, Peter

CK

Chun Kit LAM

Tue, Sep 10, 2024 9:06 AM

Should not be too hard. In fact I am looking at rewriting openscad
interpreter, and probably how it interact with the geometry backend.
Ideally these should run in a separate process from the GUI, so managing
resources become simpler. Rewriting the interpreter should also make it
a lot faster, and probably easier to extend later if designed well. I
just need a bit more time to do that...

On 10/9/2024 15:53, Peter Kriens via Discuss wrote:

The rendering process cannot be canceled and the GUI is unresponsive.
I see discussions of this on

https://github.com/openscad/openscad/issues/1195
https://github.com/openscad/openscad/issues/1901

However, it is discussed to run the rendering in a separate thread. In
another project, we had a similar problem with libraries that are not
well behaved in a multi threaded environment and even could crash. (I
have a OpenSCAD library that hangs the process when it gets wrong
data.) We ran those programs in another process, perfect isolation.
You can easily kill that process when the result is no longer needed.

Nowadays, starting a process and getting the result is lightingly fast
and the amount of time spent on this part is dwarfed by the rendering
time.

It is generally easy to do and I think Openscad can already be used as
a command line application?

Regards,

Peter

OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org

Should not be too hard. In fact I am looking at rewriting openscad interpreter, and probably how it interact with the geometry backend. Ideally these should run in a separate process from the GUI, so managing resources become simpler. Rewriting the interpreter should also make it a lot faster, and probably easier to extend later if designed well. I just need a bit more time to do that... On 10/9/2024 15:53, Peter Kriens via Discuss wrote: > > The rendering process cannot be canceled and the GUI is unresponsive. > I see discussions of this on > > https://github.com/openscad/openscad/issues/1195 > https://github.com/openscad/openscad/issues/1901 > > However, it is discussed to run the rendering in a separate thread. In > another project, we had a similar problem with libraries that are not > well behaved in a multi threaded environment and even could crash. (I > have a OpenSCAD library that hangs the process when it gets wrong > data.) We ran those programs in another _process_, perfect isolation. > You can easily kill that process when the result is no longer needed. > > Nowadays, starting a process and getting the result is lightingly fast > and the amount of time spent on this part is dwarfed by the rendering > time. > > It is generally easy to do and I think Openscad can already be used as > a command line application? > > Regards, > > Peter > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email todiscuss-leave@lists.openscad.org

GS

Guenther Sohler

Tue, Sep 10, 2024 9:40 AM

PythonSCAD does not only use a CGALWorkeer but also a CSGWorker, which are
separate threads from GUI and help to not block GUI.
(in case when python-interpreter takes some time to calculate some fancy
point coordinates)

The extra CSG Worker is just disabled for mac build, as there are some
memory problems.

On Tue, Sep 10, 2024 at 11:06 AM Chun Kit LAM via Discuss <
discuss@lists.openscad.org> wrote:

Should not be too hard. In fact I am looking at rewriting openscad
interpreter, and probably how it interact with the geometry backend.
Ideally these should run in a separate process from the GUI, so managing
resources become simpler. Rewriting the interpreter should also make it a
lot faster, and probably easier to extend later if designed well. I just
need a bit more time to do that...
On 10/9/2024 15:53, Peter Kriens via Discuss wrote:

The rendering process cannot be canceled and the GUI is unresponsive. I
see discussions of this on

https://github.com/openscad/openscad/issues/1195
https://github.com/openscad/openscad/issues/1901

However, it is discussed to run the rendering in a separate thread. In
another project, we had a similar problem with libraries that are not well
behaved in a multi threaded environment and even could crash. (I have a
OpenSCAD library that hangs the process when it gets wrong data.) We ran
those programs in another process, perfect isolation. You can easily
kill that process when the result is no longer needed.

Nowadays, starting a process and getting the result is lightingly fast and
the amount of time spent on this part is dwarfed by the rendering time.

It is generally easy to do and I think Openscad can already be used as a
command line application?

Regards,

Peter

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

PythonSCAD does not only use a CGALWorkeer but also a CSGWorker, which are separate threads from GUI and help to not block GUI. (in case when python-interpreter takes some time to calculate some fancy point coordinates) The extra CSG Worker is just disabled for mac build, as there are some memory problems. On Tue, Sep 10, 2024 at 11:06 AM Chun Kit LAM via Discuss < discuss@lists.openscad.org> wrote: > Should not be too hard. In fact I am looking at rewriting openscad > interpreter, and probably how it interact with the geometry backend. > Ideally these should run in a separate process from the GUI, so managing > resources become simpler. Rewriting the interpreter should also make it a > lot faster, and probably easier to extend later if designed well. I just > need a bit more time to do that... > On 10/9/2024 15:53, Peter Kriens via Discuss wrote: > > > The rendering process cannot be canceled and the GUI is unresponsive. I > see discussions of this on > > https://github.com/openscad/openscad/issues/1195 > https://github.com/openscad/openscad/issues/1901 > > However, it is discussed to run the rendering in a separate thread. In > another project, we had a similar problem with libraries that are not well > behaved in a multi threaded environment and even could crash. (I have a > OpenSCAD library that hangs the process when it gets wrong data.) We ran > those programs in another *process*, perfect isolation. You can easily > kill that process when the result is no longer needed. > > Nowadays, starting a process and getting the result is lightingly fast and > the amount of time spent on this part is dwarfed by the rendering time. > > It is generally easy to do and I think Openscad can already be used as a > command line application? > > Regards, > > Peter > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

PK

Peter Kriens

Wed, Sep 11, 2024 7:24 AM

Sounds great, the time is the problem for many I guess.

If it wasn't for my intense hatred for native code, based on too much experience, I'd offer to help out :-)

Will this involved having am independent representation of the 3D model so that another backend could be used? The OCCT backend looks very interesting since it can also generate STEP and it looks a lot more efficient for models with lots of groundings. I guess it will be hard for the $fn/$fs/$fa more or less give away that the model has no curves?

Exciting,

Peter

On 10 Sep 2024, at 11:06, Chun Kit LAM via Discuss discuss@lists.openscad.org wrote:

Should not be too hard. In fact I am looking at rewriting openscad interpreter, and probably how it interact with the geometry backend. Ideally these should run in a separate process from the GUI, so managing resources become simpler. Rewriting the interpreter should also make it a lot faster, and probably easier to extend later if designed well. I just need a bit more time to do that...

On 10/9/2024 15:53, Peter Kriens via Discuss wrote:

The rendering process cannot be canceled and the GUI is unresponsive. I see discussions of this on

https://github.com/openscad/openscad/issues/1195
https://github.com/openscad/openscad/issues/1901

However, it is discussed to run the rendering in a separate thread. In another project, we had a similar problem with libraries that are not well behaved in a multi threaded environment and even could crash. (I have a OpenSCAD library that hangs the process when it gets wrong data.) We ran those programs in another process, perfect isolation. You can easily kill that process when the result is no longer needed.

Nowadays, starting a process and getting the result is lightingly fast and the amount of time spent on this part is dwarfed by the rendering time.

It is generally easy to do and I think Openscad can already be used as a command line application?

Regards,

Peter

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Sounds great, the time is the problem for many I guess. If it wasn't for my intense hatred for native code, based on too much experience, I'd offer to help out :-) Will this involved having am independent representation of the 3D model so that another backend could be used? The OCCT backend looks very interesting since it can also generate STEP and it looks a lot more efficient for models with lots of groundings. I guess it will be hard for the $fn/$fs/$fa more or less give away that the model has no curves? Exciting, Peter > On 10 Sep 2024, at 11:06, Chun Kit LAM via Discuss <discuss@lists.openscad.org> wrote: > > Should not be too hard. In fact I am looking at rewriting openscad interpreter, and probably how it interact with the geometry backend. Ideally these should run in a separate process from the GUI, so managing resources become simpler. Rewriting the interpreter should also make it a lot faster, and probably easier to extend later if designed well. I just need a bit more time to do that... > > On 10/9/2024 15:53, Peter Kriens via Discuss wrote: >> >> The rendering process cannot be canceled and the GUI is unresponsive. I see discussions of this on >> >> https://github.com/openscad/openscad/issues/1195 >> https://github.com/openscad/openscad/issues/1901 >> >> However, it is discussed to run the rendering in a separate thread. In another project, we had a similar problem with libraries that are not well behaved in a multi threaded environment and even could crash. (I have a OpenSCAD library that hangs the process when it gets wrong data.) We ran those programs in another process, perfect isolation. You can easily kill that process when the result is no longer needed. >> >> Nowadays, starting a process and getting the result is lightingly fast and the amount of time spent on this part is dwarfed by the rendering time. >> >> It is generally easy to do and I think Openscad can already be used as a command line application? >> >> Regards, >> >> Peter >> >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

discuss@lists.openscad.org

Responsiveness