This commit should address the problems mentioned into #2675.
Here we moved the state apply, the skeleton updateWorldTransform and the slot objects update together with the state and skeleton update.
The whole state is now always in sync.
Methods where renamed like this:
_updateState -> _updateAndApplyState
_applyState -> _validateAndTransformAttachments
However, this has the drawback that the constructor cannot invoke the _updateState, now _updateAndApplyState, otherwise the setup pose is always rendered.
That call was probably there to calculate bounds. It was removed.
Instead, the very first time updateBounds is called - for example when the user invoke getBounds, the _updateAndApplyState is called to guarantee the bounds are calculated with a state that reflects what the user wants.
@GoodBoyDigital What do you think about this modifications?
This commit should address the problems mentioned into #2675.
Here we moved the state apply, the skeleton updateWorldTransform and the slot objects update together with the state and skeleton update. The whole state is now always in sync. Methods where renamed like this:
_updateState->_updateAndApplyState_applyState->_validateAndTransformAttachmentsHowever, this has the drawback that the constructor cannot invoke the
_updateState, now_updateAndApplyState, otherwise the setup pose is always rendered. That call was probably there to calculate bounds. It was removed.Instead, the very first time
updateBoundsis called - for example when the user invokegetBounds, the_updateAndApplyStateis called to guarantee the bounds are calculated with a state that reflects what the user wants.@GoodBoyDigital What do you think about this modifications?