slow AE and update speed. Is this normal?

[GoogleCodeExporter]

Hi Hradec
First. thanks for the new slum version F. I just download it and installed it 
(nice UI stuff).  So the 
thing is, I'm writting a quite complex slum shader for 3delight for some time 
now. The main 
problem I 'm facing is that as the shader getting bigger and the AE more 
complex, the shader 
Attribute Editor gets very slow. When pressing the update button to update my 
SLUM shader speed 
is also very slow. Something else that I've noticed in the new version F is 
that, after a render has 
finished I have to wait some seconds for AE to update. This I guess is 
something that has to do with 
the new preview button you added which tries to update each time a render 
happens. I just wanted 
to know what causes the slowness. Cheers!

Original issue reported on code.google.com by iosifkef...@gmail.com on 12 Feb 2009 at 12:05

[GoogleCodeExporter]

Is it slower than alphaD? could you send me the slum template? just strip out 
the
code in the delight method... Would be nice to have the parameters method 
intact so I
can test the UI speed on my end... 

slum uses custom maya UI calls to build the UI dinamically... thats probably 
why the
slowness.. I was thinking about implement it in a diferent way, but It will 
take some
time... So, if its critical for you I can bump it to the top of the list... 

Original comment by hra...@gmail.com on 12 Feb 2009 at 12:12

[GoogleCodeExporter]

Thanks for responding so fast. I'll send you the template via email right away..

Original comment by iosifkef...@gmail.com on 12 Feb 2009 at 12:37

[GoogleCodeExporter]

you can send it to slum@hradec.com. :D

Original comment by hra...@gmail.com on 12 Feb 2009 at 12:44

[GoogleCodeExporter]

By the way, I'm glad you're using slum for your projects... I didn't knew that
someone was actually using it for production!

Original comment by hra...@gmail.com on 12 Feb 2009 at 12:51

[GoogleCodeExporter]

Just a quick update on the issue... I think I found a way to speed up the UI for
shaders like yours, with loads of parameters. 
The trick is build the UI for the parameters in a group, ONLY IF THE GROUP is 
open.
For closed groups, the UI is not build. 
I did a test and it makes the UI way faster, with ONE inconvenient... it only 
works
if the groups are closed. If you leave all of then open, it will be slow like 
it is
today. 
One thing I could do is everytime you select the shader, the UI closes the 
groups
automatically. That makes the interaction waaaaaaaaaaaaaaaaaaaay faster, but 
has the
inconvenient that you need to open the groups you want to work with everytime 
you
show it up in the Attribute Editor. 

I could make this automatically if a shader has more than N attributes, this way
smaller shaders will continue to behave as they do today... 

What you think? 

PS: this doesn't solve the problem when creating a new node. The creation time 
is
still the same, for now.  

Original comment by hra...@gmail.com on 4 Mar 2009 at 5:09

[GoogleCodeExporter]

"I could make this automatically if a shader has more than N attributes, this 
way
smaller shaders will continue to behave as they do today..."

This sound like a good solution for now. Thanks for taking the time to deal 
with this.

Original comment by iosifkef...@gmail.com on 5 Mar 2009 at 8:43

[GoogleCodeExporter]

I'm also working on a caching system for UI. It means that the first time you 
open a
node in the attribute editor, it will be a bit slow, but any sub-sequent access 
to
that node in the AE will be instantaneous... 

Hopefully I got it working for the next alpha... I'll keep you informed. 

Original comment by hra...@gmail.com on 20 Mar 2009 at 4:36

[GoogleCodeExporter]

Original comment by hra...@gmail.com on 2 Apr 2009 at 5:15

• Changed state: Started