silhouette slowness when painting

[moondog]

a few of us are noticing that silhouette is running a lot slower than it used to when painting, we're on 3.0.4.
I used to be able to paint a spot, quickly move to the next frame, paint another spot, quickly move to the next frame. Can't do that any more & I loose my flow. I'll paint a spot, it will hang, then takes ages to go to the next frame. Just curious if anyone else is having problems, it may well be the network here at work or some other local problem. thanks

[marcop]

If you have the files you are painting on your local disk, do you still have the problem?

[moondog]

yes, even when local

[marcop]

Mac, Windows, Linux?

Can you tell me the size of your images in pixels , the it depth of your Session as well as the length of your sequence?

What size brush are you using?

[jbills]

3.0.3 solved a stickiness problem when painting quickly, but I still get the occasional slowdown and instability. we've been trying to pinpoint exactly what's going on.

it does seem to be more of an overall slowdown, and really limited to paint. roto's fine.

the most telltale sympton that pops up - the brush outline will disappear when releasing a paint stroke. it will change the cursor to the arrow pointer and leave you unable to paint. the only way to bring it back is to do something that refreshes the outline, like hit shift+drag to change the clone offset or hit crtl+drag to change the brush size.

it's intermittant, comes and goes.

at first it seemed network related, but localizing all files I guess doesn't fix it, because we've been trying that but people are still reporting issues. it happens when using small brushes, around 2 or 3. that doesn't seem to be a factor. but we know that using huge brushes slows things down.

we're on linux, 16bit float, 2678x1556 frame size, stereo

one thing I've noticed is that recently our paint projects have been getting more and more complex, and there's a lot more data being run through silhouette in terms of having 3 or 4 clone sources working at once. I'm convinced it's that our projects have gotten worse and that it's not a bug that's crept in from a dot release. I'm pretty sure it used to do this same thing back on 3.0 and 3.0.1, just noticing it more now that we're really cranking and pushing the limits more.

moondog, are you doing stuff like this? because it seems to happen less when just doing dustbusting or simple jobs using a single clone source, not in stereo.

I would suggest localizing all source files, lowering maxRAM pref cache to 1500, playing with paint undo #'s, not running email or flipbooks on the same machine, checking that the slowdown occurs with the mouse as well as the tablet when it's happening, etc.

let's try to pinpoint what's triggering this. i have a feeling it's cache or RAM management related.

paul, can you think of anything that would help narrow this down?

[jbills]

oh, just noticed moondog is in portland.

trish is that you?

:)

[moondog]

yip its me, we sit about 10 feet from each other. I was having the slowness problem on Sunday with no one around (had thought that might be a factor). It was a simple stero job with one clone sauce. Wasn't localised, but I never localised in the past.

[jbills]

you seem to be convinced it's the new version.

why not test it? I can't because I need the bug fixes in the new version.

to roll back to the old version, you can start from the command line by using sil 3.03_rc1 etc you can go back as far as you want.

I'd wait until you start a new shot and not switch in the middle (so as not to break compaitibility), but you're more than welcome to change versions manually if you think it's something to do with the new version.

[moondog]

no i'm not convinced it the new version. all i know is that its a lot slower than it used to be & I'm wondering if anyone else out there is experiencing similar problems.

[michael_brazelton]

we are having problems here with paint slowness as well - we just moved to 3.0.4 and it's happened to a few people -

they moved their images to a local drive and it seems to be helping - but in general still slower....


any ideas out there?

[michael_brazelton]

so we have found that using the sinc filter instead of the default (mitchell) slows it down a lot!

anyone else finding that?

[paulm]

Some filters are much slower than others (and don't look that much different).

Are you saying the actual PAINTING is slow or after you paint or changing frames?

[michael_brazelton]

its actually sticking once a stroke has been made when using the sinc filter. can stick for up to 10 secs before updating. this was only happening after a day of painting...i.e. quite a few paint strokes.

[paulm]

Was this immediately after an undo or redo?

Were all the strokes on the same frame or was this spread over many frames?

Did you detect a lot of disk activity while this was happening?

[michael_brazelton]

it was on every frame, throughout the time i was using it, regardless of undos or redos. didn't detect a lot of disk activity

[jbills]

2k or larger?

i've had a hard time painting at 4k, but not like 10 sec

[paulm]

Good point - can you guys post OpenGL driver info from the console?

[hkmacphee]

i'm getting it too.. Just started a new paint project and painted the first frame, and had major lag time on the brush response. It was so annoying I had to quit out of the program and restart it again. I don't know if size does have a factor in it, but it does seem the like the bigger brush sizes, like about 50, is having some difficulty. 3.0.4 seems to be having quirks that 3.0.3 didn't have. i am also using about 3 clone stores, and i usually like to move pretty rapidly back and forth between frames.

[michael_brazelton]

we are painting at 2k - I'll post the open gl info in a bit!

[michael_brazelton]

is this what you want?

OpenGL driver information
Vendor: NVIDIA Corporation
Renderer: Quadro FX 1500/PCI/SSE2
Version: 2.0.2 NVIDIA 87.76

?

there is a slew of other stuff under it I can post....

[paulm]

The Quadro FX 1500 shouldn't be the problem - as long as you're running the proper HW accelerated graphics driver.

3.0.4 made an optimization that was meant to help with the paint lag between strokes. One second after releasing a stroke, if no other strokes have started, it will generate the result image, which can take some time if there is a lot of paint on a frame and if the images are large.

I can see now that it might be necessary to adjust the way paint is composited within the paint tool - possibly divert the compositing until after you leave the frame. This would disable things like painting while viewing the output/composite, but I suspect that would be a fair trade.

Note that my main machine is a quad 2.6Ghz running Windows XP and I see no such lag. It could be that the windows compiler is just generating much better code than gcc on Linux.

[michael_brazelton]

I suppose there being a million dif types of linux around doesn't help!

[michael_brazelton]

is there a flavor of linux you recommend? I'm not sure what we have access to - but if that will fix all our probs I"ll see about switching to it...