THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/02/2007 at 18:42, xxxxxxxx wrote:
Cinema 4D Version: R10
Platform: Mac OSX ;
Language(s) : C++ ;
I don't know where to begin here. The problem is best described like so:
In Cinema 4D R10 on MacOSX (Universal Binary, of course), when there is one of my plugin objects that has lots of sliders added to the Attributes Manager (Dynamic Descriptions), the MacOS 'beach ball' comes up constantly when trying to scroll the list, change the slider values, or even just moving the mouse around the A.M. Less sliders, no beach-ball (an exact number hasn't yet been determined).
This behavior is not seen on any other version of this plugin (R8.2-R10, Win32, Win64, PPC, R9.5UB). Only R10 UB behaves this way. The code here (GetDDescription()) is identical for all versions. I can only think of three possible causes - The R10 compile/link is creating an unstable plugin (but the same version of XCode is used for R9.5UB w/o this problem), R10 itself is manifesting a problem in this respect, or the LoadDescription() at the top is having problems with the new MacOS filesystem access.
The reason that the last seems relevant is that this is the only place where there is the new filesystem access (Windows doesn't need this and older versions with UB had different access).
For now, I'm picking at straws as the reason is indeterminate.
On 07/02/2007 at 02:04, xxxxxxxx wrote:
I will look into it. But how many sliders are we talking about approximatly? Also this is maybe a bug of the Mac version of Cinema.
On 07/02/2007 at 02:35, xxxxxxxx wrote:
Well, the 'impedence' seems to increase with the number of dynamic sliders added. Let's say that at about 50 or so, the beach ball appears.
I'm currently planning on commenting out portions of the GetDDescription() code to narrow down what part may be the main factor here - will reply back if something identifiable occurs.
Thank you very much,
On 07/02/2007 at 21:55, xxxxxxxx wrote:
Interesting stuff here.
Remember there is a slider and button for each item (2 columns for the group).
Commenting out the slider part has minimal affect (just the buttons show). The beach ball still appears, but less frequently. You say 'okay'.
Commenting out the button part has a very positive affect (just the sliders show). Counterintuitively, the more complex sliders have no impedence at all! Add the buttons, and the beach-ball appears (sliders or not!).
I'm calling this one. The buttons are the problem here. Why? Good question. Could not setting a particular DESC definition in R10 be taking an incorrect, unexpected, or disadvantageous default value?
Currently, these are set for the Button BaseContainer:
// In init, general settings
editBC = GetCustomDataTypeDefault(DTYPE_BUTTON);
// later on, per slider
Note that DESC_HIDE is set to either TRUE or FALSE depending upon the state of showing the item (slider+button).
On 08/02/2007 at 00:11, xxxxxxxx wrote:
Okay, I take that back. This is definitely a matter of numbers. The more description elements, the worse the performance.
Taking out the Buttons only helped because there were less descriptions. But in order to retain 2 columns when the buttons are not added, I substituted a Separator and the performance is just as bad.
This performance degradation in the Attributes Manager is not seen at all in R9.6 or earlier, only R10. The developers might want to take a gander at their code changes in this respect. It has also been noted at CGTalk that the number of tags on an object can cause R10 to become sluggish. Since these sliders are based upon tags (albethey hidden), this could be an avenue to investigate as well - but I'm still inclined towards description numbers in this case.