tomvanmele
commented
5 years ago first of all, sorry for replying so late! most of my reply is now obsolete, but i will answer anyway :)
I suspect that each time an macro is invoked, the python script has to load a cached .json file, or loads geometry stored in designated layers. That is the state of the program isnt kept in memory, but is being rebuild.
the way the "old" compas ui system for Rhino works is by using a front controller. the methods of the front controller are bound to the buttons of the toolbar. the front controller also stores an instance of the current form and force diagrams which are constantly updated and modified by the various actions assigned to the buttons. once loaded, the data is thus live and doesn't need to be reloaded, nor is it stored in Rhino geometry or layers. in fact, the Rhino geometry is just a representation of the current state of the live data.
for example, if you delete the entire form diagram and subsequently compute horizontal equilibrium, the tool will not complain and simply draw the new form diagram when the results of the algorithm are available.
the perceived lag of some of the methods of compas_tna is most likely related to the fact that much of the computation is handled by Numpy/Scipy based algorithms which have to be run through an external process. in the past this was handled with so-called XFuncs. although this was quite convenient, an XFunc has the downside of starting a separate Python interpreter for every call and thus creates a lot of overhead. This has now been replaced with the much faster system of Remote Procedure Calls.
So the hunch here is that creating a ETO based UI is low hanging fruit, also since the actions already defined are easily hooked to such an ETO based UI. The upside here is that while the UI loop is running, the TNA mesh is kept in memory, hence quite a boost in responsiveness is to be expected
as you will see in the current version of the package, we have been working towards more transparent cross-platform UI implementations by using Python-based command plugins. the individual commands use the sticky dict of the scriptcontext to keep data alive across calls and could be linked to command buttons much like the methods of the front controller that was used before.
i assume though that you are talking about a single ETO form that handles the entire event loop of a TNA design session and therefore automatically keeps all data alive without the need for the sticky dict.
anyway, this is all still very much under construction but should be reaching a certain level of maturity as we approach the first full release of COMPAS at the beginning of the summer.
let me know what you think!
jf---
Moving from .rui -> ETO ui
there's a method
rui_makethat generates a .rui file, a toolbar that calls python scripts. In summary hitting a button invokes amacro.Details
Is your feature request related to a problem? Please describe.
( I'm making some assumptions here, I hope these are correct. Havent utilized the toolbar since working from RhinoMac )
I suspect that each time an macro is invoked, the python script has to load a cached .json file, or loads geometry stored in designated layers. That is the state of the program isnt kept in memory, but is being rebuild.
So the hunch here is that creating a
ETObased UI is low hanging fruit, also since the actions already defined are easily hooked to such anETObased UI. The upside here is that while the UI loop is running, the TNA mesh is kept in memory, hence quite a boost in responsiveness is to be expectedThat stated, stoked to read the crisp and clean
compas_tnacode!