Gui Performance Gets Slow

[user_deleted]

hi,

when i built a big shake tree. the GUI performance gets really slow. to move a node or a noodle is really hard.
also when i paint or roto, as long as the node viewer is displayed it gets sloooow.

if the trees is to big it doesnt help when i clear the cache. /var/tmp/....

is there something to setup in the shake settings.

i have a G5 quad with GeForce 7800GT.

[user_deleted]

we have noticed that the performance of the gui is pretty craptacular if you are not saving the script files to your local machine or better you home directory !

[deke-kincaid]

what version of osx and what version of shake?

[user_deleted]

really ?! it also depends where the script files are saved. wow, funny.

i have OS X 10.4.6 G5 quad, 4.5 GB RAM and a HugeRaid (level 3) and Shake 4.

i have modified the nreal.h file.

cache.cacheMemory = 256;
diskCache.cacheSize = 256;
diskCache.cacheMemory = 256;

but the performance isnt better. my shake script is 276kb...

[user_deleted]

As far as I remember the Shake gui is using openGL. So if your graphics card is a bit weak (or not set up properly), it might get slow.

Just another stab in the dark,
FR

[user_deleted]

yes maybe it would help when nvidia is supporting os x... i hope this will be soon so!

but i have a GeForce 7800GT card. and i guess this card is fast and clever enough to use openGL.

in the os x system profiler i cant find any opneGL information. is there maybe a tool to tweak some graphic card settings?

...or.....is it normal that shake

[user_deleted]

80-120 FI nodes is definitely the kind of thing that can make things go slooooooow in Shake's GUI, and that has nothing to do with OpenGL(or very little impact compared to other slow-downs). Keep in mind that Shake reads and re-compiles the whole script every time you change from one frame to another, or even every time you change a parameter's value. That means reading the whole script again, looking for all FileIn's again, evaluating any expression you might have set, everything!

You should keep that in mind when building complex scripts. I often find myself using a manual update to avoid this kind of lags

By the way, do you really really need those 80-120 File-ins in a single script?????

[deke-kincaid]

heh, 80-120 filein nodes? damn! That won't just make shake slow, but just about any compositor. Turn off the node icons in the globals, that will speed it up a lot. I would also look at precomping parts of your tree.

How big is a "huge raid"? and how fast is it and are we talking local or on a server your pulling over ethernet, fiber, scsi, sata? What resolution frames? SD, HD, 2k? 80-120 filein's is a crap load of i/o, especially if your reading over a network.

[user_deleted]

yes, i need all this FI nodes. ok i have 3 trees. but this are similar shots and i need to match them. so i need nearly the same colorcorrection nodes. i can easy switch to the other trees and match all.
the 3D gusy support me all the time witch new renderlayers. sometimes for the 1st tree, then for the 3rd......
so i need this in one script. and i need to check the layer asap.

would it maybe better to make 3 scripts and launch shake in 3 instances?

my files are all local on the raid. i would say the trasnferrate is 150MB/s. its raid 3. the size is 1TB.
25fps, 2000*1200 pix, 16bit, iffs

all my files are on the raid in a defined folder structur.

i have not a lot of expressions. most "expression" is just a FI node clone to mask some parts at the end...blah.

i mean if a compositor have a complex shot with cg, livefootage, keyers, cc, log-lin and backwards, cin or sgi in 2k-4k. how big will his tree be.

"That won't just make shake slow, but just about any compositor"

for sure if you have a tree like this you should never knock against your head.

[deke-kincaid]

Your reply is a little confusing here. Do you mean 80-150 nodes total or 80-150 file-in nodes?

[user_deleted]

sorry if i confusing you.

i mean 80-120 FI nodes. not included are cc or compositing nodes!