Any chance of getting the Krakatoa render dialog to open a bit faster?
Also, when using RPManager, it seems to get closed every time you do a render?
How slow is it? You can see the time it takes to open in the Krakatoa Log.
When Deadline detection is enabled, it can take a while the first time you open it because it has to pull all SMTD functions from the Repository and load the default and sticky settings.
On my machine, with Deadline Detection off, it takes around 2 seconds to open.
With Deadline detection on, the first time it can take a lot longer depending on the speed of the network. Here it takes around 10 seconds.
Once SMTD is initialized, it should open faster again.
The closing of the dialog is most probably caused by a Max Notification sent due to changes to the renderer - Krakatoa GUI closes on #postRendererChange, #systemPostReset, #systemPostNew and #filePreOpen. You can also open the Krakatoa Log, switch to Debug Logging Level and watch for a message like
DBG: >Krakatoa GUI Floater Closed by #SystemPostNew Callback.
or something similar. The type of the callback will tell us what RPM is doing to cause this.
Let me know what it is…
Ah, I get it, RPManager is doing something to the render dialog so it then closes the dialog. Could I turn that off without it causing problems?
Oh, and where do i find the log file?
In the Preferences rollout, there is a button “Open The Log Window Now!”. Also, you can customize a Krakatoa toolbar and put the Log icon there, as I have begged publicly in my blog 
lotsofparticles.blogspot.com/200 … -your.html
In theory, I could rework the mechanism of closing the dialog to not close automatically when the scene or renderer changes but to stay open and disable access to buttons if the renderer is not Krakatoa, but that is a lot more complicated. You could try to delete the corresponding callbacks or remark them completely from KrakatoaGUI.ms, but it could be a problem when switching between Krakatoa and other renderers.
To answer your question about GUI speed, Im getting 3453ms.
Thanks.
I had made some progress in early 1.5 development by completely disabling rollouts that are hidden.
Unfortunately, I had to revert these changes because not having all rollouts initialized AND displayed could cause severe problems with saving and loading settings, even with using some of the visible rollouts. All the hidden rollouts are still being added to a floater, just off-screen so they don’t clutter the UI. But they are still initialized, updated and added on startup, so this is the performance hit of having them all.
In theory, I could work on removing any functionality from the rollout scope and moving it to the global functions struct to allow rollouts to be completely uninitialized. For example, the VFB Extensions in 2009 and higher depend on the data generated by the Channels rollout about memory channels to update the memory channel list in the VFB’s bottom panel, and the list goes on. Still, saving a preset or history record while rollouts are hidden would make it impossible to save the states of the corresponding controls because the loading/saving uses the actual UI controls values and not the internal properties they represent. This is mainly because many controls map their values differently to the UI to make it easier to the user to select the right mode, thus internal values would be difficult to decipher when looked at in the Presets and History rollout.
I will try to add some more profiling code to the DBG output of the Log file to figure out how long it takes to update and add each rollout to the UI in hopes to find some rollouts that are slower than others and try to optimize them. Currently there are 15 rollouts to be added which means that on your machine, each takes about 230.2 ms, and on mine is around 140 ms. It sounds plausible. Removing some rarely used rollouts completely (like About, Notes etc.) or combining them into fewer rollouts could help a bit.
I will look closer into this…
Ok, I added some profiling code and here are my results in the current version:
DBG: +Processing ‘Main Controls’ took 234ms.
DBG: +Processing ‘Save Particles’ took 94ms.
DBG: +Processing ‘Global Render Values’ took 141ms.
DBG: +Processing ‘Channels’ took 93ms.
DBG: +Processing ‘Partitioning’ took 219ms.
DBG: +Processing ‘Matte Objects’ took 156ms.
DBG: +Processing ‘Ambient PME’ took 172ms.
DBG: +Processing ‘Scene Particle Systems’ took 78ms.
DBG: +Processing ‘Particle Loaders’ took 110ms.
DBG: +Processing ‘Shadows On Geometry’ took 47ms.
DBG: +Processing ‘Preferences’ took 171ms.
DBG: +Processing ‘User Notes’ took 47ms.
DBG: +Processing ‘About’ took 219ms.
DBG: +Processing ‘Presets and History’ took 63ms.
PRG: +Krakatoa GUI Floater OPENED in 2000ms.
(the above rollouts account for 1833 ms, there is some more happening inside the opening sequence, but in general this is a good reference).
Then I disabled the ON OPEN DO handlers of all rollouts to see how much is done inside the initialization of all the UI controls.
DBG: +Processing ‘Main Controls’ took 172ms.
DBG: +Processing ‘Save Particles’ took 78ms.
DBG: +Processing ‘Global Render Values’ took 110ms.
DBG: +Processing ‘Channels’ took 62ms.
DBG: +Processing ‘Partitioning’ took 141ms.
DBG: +Processing ‘Matte Objects’ took 109ms.
DBG: +Processing ‘Ambient PME’ took 125ms.
DBG: +Processing ‘Scene Particle Systems’ took 47ms.
DBG: +Processing ‘Particle Loaders’ took 110ms.
DBG: +Processing ‘Shadows On Geometry’ took 46ms.
DBG: +Processing ‘Preferences’ took 125ms.
DBG: +Processing ‘User Notes’ took 32ms.
DBG: +Processing ‘About’ took 47ms.
DBG: +Processing ‘Presets and History’ took 62ms.
PRG: +Krakatoa GUI Floater OPENED in 1391ms.
These rollouts do not get set to their current/default settings and account for 1266 ms out of 1391. In other words, 576 ms are lost in the ON OPEN DO handlers. The rest is pure adding and drawing of the rollouts into the floaters.
Interestingly, I am getting similar results when moving ALL rollouts to Hidden state (Manage Krakatoa GUI Rollouts > Move all to left column) because all rollouts are added to the offscreen floater in rolledup state and thus do not redraw all buttons/spinners/other controls.
So you could try hiding all rollouts except for the 4-5 you actually use and see if this speeds up things a bit.
At this point, I think it is simply MAXScript that is lagging in building all these controls.
I think finding a way not to close the UI on RPM activity would be a better approach to your problem…