gui launch times

Deprecated Krakatoa 1.5 Beta Discussion
1

Launching the krakatoa scripted gui is pretty slow. It seems even slower because we use rpmanager which reloads the panel (or closes it) when you switch passes, so it’s constantly reloading.

The dialog appears right away. Then there is a few seconds of flickering while everything initializes and rollouts add all their items. Rough estimates are around 4-5 seconds.

I’m hiding:
Partitioning
Ambient PME
Thinking Particle Groups
Shadows On Geometry
user notes
About.

That leaves 9 remaining rollouts.

Anything we can do on our side or on your side?

Thanks,
Ben.

2

Just my opinion but for such a large scripted UI it is pretty quick. The best thing that I have found is to just get in the habit of minimizing the interface instead of closing it.

3

Hi Ben,

It is probably not obvious, but unfortunately hiding rollouts does not speed up the UI.
We added the system for hiding rollouts mainly to reduce the clutter and make navigation easier, but the “hidden” rollouts are still initialized and added to a 3rd rollout floater which is simply offscreen. This was necessary because a lot of operations like saving history, saving presets or using the extended VFB controls require those hidden rollout to actually be open and initialized.

In the Beta 2 of v1.5.2, we added a new MacroScript with an F! icon (this means Front! or Focus!, not F#@k!) which tries to bring the Krakatoa GUI to the front if it is behind other windows. Unfortunately, I could not get it to maximize the floater if it is minimized. So right now the best way is to open Krakatoa and keep it open, even if it is behind MatEditor, Listener, Scene Explorer or whatever. When you need it, hit F! and it will come to front.
This of course does not solve the problem when you have to switch between Krakatoa and other renderers.

I have done measurements and while I know it is quite slow, I don’t think there is much that could be done. I could try to eliminate half of the rollouts nobody uses (Notes, About, APME, TP, Shadows On Geometry, Scene Particles etc.) and see if there would be much speed increase. I could make some of them separate utilities (for example Preferences and the History rollout could be separate tools like the Schematic Flow already is). This would leave us with the Global Overrides, Main Controls, Saving, Channels and Matte Objects.

For v2.0, we have plans to split the saving particles functionality from the rendering functionality, so all saving controls will be likely in a completely separate UI. That might help.

I don’t think there is an easy way to improve startup times as we did for SMTD, but I will keep on looking into it…

Here is the timing from my machine’s Log in Debug mode:

PRG: -----2/19/2010 11:46:21 AM--------------------------
PRG: >Opening Krakatoa GUI…
PRG: >Detecting Deadline Render Manager…
PRG: +Submit Max To Deadline Functions 3 or higher ALREADY LOADED!
DBG: +Created Krakatoa GUI Floater At Last Position Stored In Renderer.
DBG: +Added ‘Shader Parameters’ Rollout to Krakatoa GUI Floater.
DBG: +Main Rollout OPENED.
DBG: +Added ‘Main Controls’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Main Controls’ took 359ms.
DBG: +Save Particles Rollout OPENED.
DBG: +Added ‘Save Particles’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Save Particles’ took 125ms.
DBG: +Render Global Values ROLLED UP or CHANGED HEIGHT.
DBG: +Added ‘Global Render Values’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Global Render Values’ took 235ms.
DBG: +Channels Rollout OPENED.
DBG: +Added ‘Channels and Memory’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Channels and Memory’ took 172ms.
DBG: +Particle Partitioning Rollout ROLLED UP.
DBG: +Partitioning Rollout OPENED.
DBG: +Added ‘Partitioning’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Partitioning’ took 328ms.
DBG: +Matte Objects Rollout ROLLED UP.
DBG: +Matte Objects Rollout OPENED.
DBG: +Added ‘Matte Objects’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Matte Objects’ took 234ms.
DBG: +Ambient PME Rollout ROLLED UP.
DBG: +Ambient PME Rollout OPENED.
DBG: +Added ‘Ambient PME’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Ambient PME’ took 266ms.
DBG: >Populating Particle Systems List with None
DBG: +Particle Systems Rollout ROLLED UP.
DBG: +Scene Particles Rollout OPENED.
DBG: +Added ‘Scene Particle Systems’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Scene Particle Systems’ took 156ms.
DBG: +Particle Loaders Rollout ROLLED UP.
DBG: +Particle Loaders Rollout - Registering SELECTION Callback.
DBG: +Particle Loaders Rollout - Registering NODE Callbacks.
DBG: +Particle Loaders Rollout - Registering WHEN Callbacks.
DBG: +Particle Loaders Rollout OPENED.
DBG: +Added ‘Particle Loaders’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Particle Loaders’ took 250ms.
DBG: +Shadows On Geometry Rollout OPENED.
DBG: +Added ‘Shadows On Geometry’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Shadows On Geometry’ took 78ms.
DBG: +Preferences Rollout OPENED.
DBG: +Added ‘Preferences’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Preferences’ took 203ms.
DBG: +Notes Rollout OPENED.
DBG: +Added ‘User Notes’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘User Notes’ took 94ms.
DBG: +About Rollout OPENED.
DBG: +Added ‘About’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘About’ took 250ms.
DBG: +Presets Rollout OPENED.
DBG: +Added ‘Presets and History’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Presets and History’ took 172ms.
DBG: +Thinking Particles Rollout ROLLED UP.
DBG: >Unregistering Callbacks…
DBG: +Thinking Particles Rollout OPENED.
DBG: +Added ‘Thinking Particles Groups’ Rollout to Krakatoa GUI Floater.
DBG: +Processing ‘Thinking Particles Groups’ took 203ms.
DBG: >Setting System Limit of all Particle Flow Emitters to 100 Million Particles…
DBG: -No Particle Flow Emitters found.
PRG: +Krakatoa GUI Floater OPENED in 3328ms.

4

Not related, but right-clicking on the buttons in the main rollout for APME, Matte Objects, etc. takes you to the relevant rollout, which is good. But it also hides the other rollouts. That seems bad to me. Is that a bug, or am I missing something about the navigation? I know I can hit the “Back to Main Controls” button, but that doesn’t restore the rollouts to the way they were.

  • Chad
5

There are issues with navigating to a rollout when the others are open (nasty redraw problems).
I could try to store the old states and restore them when using Back To Main Controls…

6

Don’t worry about it, I thought it was a bug on your side.

7

hmmm. I wonder if a flash or .net interface would be faster.

KrakatoaGui.ms is over 14000 lines of maxscript! Wow! How much is getting re-evaluated every launch?

When I ctrl-right-click in the editor to browse the functions it fills my entire monitor. I should post a screenshot.

The rpmanager gui has at least as many buttons and options. And that is faster, despite the slow initialization of the .net grid view.

Well, like I said, if rpmanager would stop closing the krakatoa gui, I’m sure I’ll go back to not noticing.

8

I suspect DotNet would be slower. Krakatoa 1.0 used to reevaluate rollouts when opening, but I changed that. Interestingly, I don’t think it affected the performance that much.
Right now, opening each rollout takes about 200 ms. It is the large number of rollouts being added that seems to slow things down. In the current version there are 16 rollouts, and I added a 17th yesterday…(you will love what it does, but it won’t be in 1.5.2) This is over 3 seconds already.

That’s why I suggested removing some rollouts and moving others to separate utilities… I will try that in the near future.

9

I took some more time to benchmark all functions involved in the opening of the GUI.
Verdict: I cannot do anything about it, because 99% of the time is eaten by the actual adding of the rollout to the floater:

local st2 = timestamp() addRollout theRollout Krakatoa_Gui_floater FranticParticles.LogDebug (" >Rollout Dock/Float: Rollout Added in "+(timestamp()-st2) as string+" ms." )

The output in the Log in Debug mode for Main Rollout is:

DBG: +Main Rollout OPENED. DBG: >Rollout Dock/Float: Rollout Added in 164 ms. DBG: >Rollout Dock/Float: Processed Not Docked in 168 ms. DBG: >Rollout Dock/Float: Processed Docking To Secondary in 0 ms. DBG: >Rollout Dock/Float: [Main Controls] Processed In 168 ms. DBG: +Added 'Main Controls' Rollout to Krakatoa GUI Floater. DBG: +Processing 'Main Controls' took 168ms.

As you can see, 164 out of 168 ms. are taken by the line ‘addRollout theRollout Krakatoa_Gui_floater’. So it is how fast MAXScript can add a rollout of that size to a floater. 4 ms. are lost in the writing to INI files and making sure the rollout is not displayed somewhere else.

Just for the fun of it, I disabled the adding of the Saving, Partitions, Particle Loaders, Particle Systems, Shadows, Notes, About and Preferences rollouts and the loading time was halved (on my home i7 based machine from 2 to 1 second). I could move some of these to separate utilities launched through the new Krakatoa menu, icons or even buttons in the Main Controls rollout.
*We intend to move the Savinig, part of the Channels rollout dedicated to channels to save as well as the Partitioning rollouts to a separate utility in the near future.
*About, Preferences, Notes, Particle Loaders and Particle Systems could also be separate utilities launched as individual MacroScripts through the menu, icons or buttons in the GUI. Neither of them is saved by presets and they are all kind of unrelated to the actual render settings.
*The one checkbutton in Shadows On Geometry is already duplicated in Main Controls, and the other button just launches the Shadows utility, so that rollout can be eliminated.

We will consider these optimizations for v2.0.

10

What part is the slowest?

Defining the rollouts.
The event handlers.
Right click menus.
Adding a rollout to a floater?

Mxs is great for rapid developement, I’m just not sure it scales this big without a performance cost.

11

Whoops, I read your last post after I wrote mine. I need to reread the details.

12

Defining the rollouts. - this happens only at launch time, except for the Shaders rollout which is now built on-the-fly as its content is now dynamic.
The event handlers. - not called, except for on theRollout open do which just calls the other functions to update. No significant hit.
Right click menus. - not involved in the process.
Adding a rollout to a floater? - yep, as my previous post shows, the MAXScript call to addRollout() takes all the time. The larger the rollout, the longer it takes.

So I cannot make the rollouts faster, all I can do is make the rollouts fewer. It actually makes sense since many of these rollouts are used rarely (Notes, Preferences, Particle Systems) or even never (how often has anyone used the About rollout for anything?). In fact, we had a poll last year about the most and least used rollouts in the UI and we know that people barely touch things like APME and Presets and History. But I think we could simply move anything that does not directly affect the rendering settings to a stand-alone dialog and keep only controls relevant to the rendering process in the Krakatoa GUI floaters.

So if you want to set up the Preferences of Krakatoa for example, you would have to select Preferences… from the Krakatoa menu or MacroScript Icon. (We might even add some more buttons to the C++ UI in the Renderer tab of the Render Dialog to make sure they are always accessible).

We could also add a new rollout in place of all of the above rollouts with buttons for opening the Preferences, Notes, Scene Particle Systems, Particle Loaders and so on utilities and call the rollout “Krakatoa Utilities”. That would be a central place for launching anything related to Krakatoa but not directly affecting its render properties…

13

I’d rather see the history and presets a part of the render frame window extensions. And I’d like the history and presets to work for all renderers. And I’d like the ram player and vfb be rewritten…and I want a pony…and world peace.

14

I figured :slight_smile:

Turns out there is a relatively simple way to shave off some time.
There are about 8 rollouts that I mentioned before which do not affect presets saving and thus do not need to be constantly open somewhere.
So I tried to disable them completely when hidden - instead of docking them to the offscreen floater, I just let them close.
On my home machine, GUI launch time was halved when I had those rollouts hidden: About, Notes, Preferences, Shadows, TP, Scene Particle Systems, Particle Loaders, Presets and History.
I will have to test a bit more, but this would be a relatively cheap way to get some speed out of 1.5.2 without reworking the whole system. (assuming you don’t need those rollouts and thus have them hidden by default).

The History would make sense in the extended VFB only if I could somehow get the VFB to update its content to the history item’s image. Unfortunately, that is not exactly supported by the current system, and extended viewports are supported only in Max 2009 and higher, while we still support 9 and 2008. So no pony for you yet…

15

Just wanted to inform you all that I did some serious reworking of both the management and the content of the Krakatoa UI, resulting in a GUI launch time of around 800 to 900 ms (on my home and office workstations). YMMV.

This included changes to the content of the Krakatoa GUI (less rollouts - only those actually related to the renderer settings will be hosted there now).
Several rollouts used rarely and for more general management were moved to dedicated tools floaters or stand-alone dialogs. The former include the Explorers (Particle Systems, Particle Loaders, Thinking Particles Groups), the latter include the Preferences, Notes and About dialogs.

There will be access to all these new components of the system from various places inside the Krakatoa GUI, the new Krakatoa Menu and the Krakatoa toolbar MacroScripts. But not having to manage rollouts that are not directly related to the rendering process reduced the startup time by half already.

The other change was that the rollouts are now added to the floaters in collapsed state and then opened if that was their last stored state. Previously, the rollouts were added to the floater in their opened state and then rolled up if that was their last stored state. This caused a lot of redraw overhead, but given that typically most of the rollouts except for the Main Controls are rolled up (like Matte Objects, APME, Global Render Values, Save Particles and Partitions to name a few), this makes sense and also shaved off about half a second…

I will keep on trying to make it even faster, but I think it is a lot better already.

16

That’s great. I’m hoping it’ll be easier to train people now too. Walls of buttons are the bane of renderers.