Hmm, well that gives me some food for thought at least. At the moment I have a dressed and morphed-up GF2 animating and I stopped it to check out if I had SubD preview turned on for anything. Lo and behold one of the shoes had SubD preview jacked up to 2 for some reason. Turned that down to zero and the result was that changing the selected bodypart no longer took 3 seconds. Changing a morph value however took around 7 seconds to finish.

Also, I am still at a loss to explain why this happens on non dressed figures, and why I don't have this problem at all in Poser Pro 2012. It must be something Poser Pro 11 specific I Guess?

ironsoul posted at 9:17PM Sun, 19 August 2018 - #4335028

I had another look at the performance calcs I did previously

Screen refresh and multithreading - looks like OpenGL is single threaded. What I was seeing before was the effect of turning on "Parallel Compute" mode. This distributes some work between CPUs but appears only one cpu can gain access to OpenGL renderer at a time (I'm basing this on looking at the performance charts and a bit of Googling, someone who actual codes with OpenGL may know differently). It could be "Parallel Compute" mode is most effective when there are complex calculations per actor to be done. The python command "poser.EnableParallelComputeActors(1)" enables this feature.

Re calculated the morph timings and got variable results, some were quicker with morphs and others not. It may be the morphs only have an impact when used but puzzled by this since applying morph transforms against the mesh should take longer.

Had a look at enabling just the selected part, did not appear to improve perceived lag when working with complex figure. Bit puzzled by this too,

My calcs (based on 500 redraws of stationary figure) V4 (no morphs) - 30 fps, V4 with Morphs++ (30 - 22 fps), G6 with sub div off = 37 fps, G6 sub-div @ 0 = 18 fps, G6 sub-div @ 1 = 8 fps

The strong do as they can while the weak do as they must.