[Backout] - CL33171468
[FYI] logan.buchy
Original CL Desc
-----------------------------------------------------------------
Performance improvement for nested FInstancedStruct in details panel
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33205050 by robert millar in ue5-main branch]
- When duplicating the Component, RandomStream was always copied from the one on Component CDO and wasn't constructed with the current time as expected. We now initialize RandomStream at FStateTreeExecutionContext::Start(), where the InstanceData is going to persist till Stop().
- Moved RandomStream variable to FStateTreeExecutionState as it better reflects the window it persists now.
- Fixed non-deterministic default-constructed value of RandomStream variable in UStruct LogError by the above
#jira UE-212551
#rb mikko.mononen
[CL 33174826 by jacob wang in ue5-main branch]
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33171500 by logan buchy in ue5-main branch]
[FYI] logan.buchy
Original CL Desc
-----------------------------------------------------------------
Performance improvement for nested FInstancedStruct in details panel
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33161624 by logan buchy in ue5-main branch]
* Pathological performance issues occurred when viewing/editing USTRUCT objects that nested FInstancedStruct (either directly or in containers). The PropertyNode system's implementation when handling FInstancedStructs would recurse up the property tree to discover the address of the owning objects and then recurse again up with the starting address. The root cause of the performance issue is that the recursion would branch on the way up in the following functions: GetInstancesNum, GetMemoryOfInstance, GetOwnerPackages, HasValidStructData (by way of IsValid). On the way up again, branches would occur in GetValueBaseAddress, via duplicate calls in FItemPropertyNode::GetValueBaseAddress to ParentNode->GetValueAddress.
* The problem has been addressed by having the StructPropertyNode handle StructProviders that perform indirection differently than other providers. When indirection is present, walk up to the parent node of the struct which will be an ItemPropertyNode - the address of this is retrieved and passed back down to the StructProvider. In the current codebase, the FInstancedStructProvider is the only one that does this type of indirection - it can make the assumption that the passed in address is an FInstancedStruct and thus reinterpret it to get the StructMemory and UStruct* pointers.
* Added an InternalGetReadAddressUncached which public GetReadAddress** functions will call. This new function will not resolve the Struct in the case of a Struct property indirection unlike GetReadAddressUncached. It is intended as an internal function only to be called by the public APIs.
* Added a safeguard canary value to FInstancedStruct to debug/catch cases where the wrong raw void* is reinterpreted as an FInstancedStruct. FInstancedStruct::CastFromVoid helper should be used over a naked reinterpret_cast
* Note that it isn't guarantees all paths where slow recursive behaviour occurs has been addressed in this CL. Specifically, the InstancedStructDetails implementations to get the dispaly values still go through the data enumeration though it should be better now that GetInstancesNum and GetMemoryOfInstance are not recursively calling the Enumerate pathways. See GetDisplayValueString, GetTooltipText, GetDisplayValueIcon, GenerateStructPicker - this is the primary expense in Slate that is probably causing additional performance loss.
#rb mikko.mononen
#jira UE-207555
[CL 33154559 by logan buchy in ue5-main branch]
allowed to provide verbosity to STATETREE_TRACE_LOG_EVENT and STATETREE_LOG_AND_TRACE so the debugger can add custom icons accordingly.
#jira UE-210505
#rb mikko.mononen
[CL 33140307 by yoan stamant in ue5-main branch]
- new recording started from the debugger will be selected as the new active analysis
- allow multiple recordings during the same PIE session to reactive existing tracks
- do not apply trace selection if user reselect the current trace to avoid clearing data
#jira UE-207595
#jira UE-207406
#jira UE-207414
#rb mikko.mononen
[CL 33099625 by yoan stamant in ue5-main branch]
- Another fix for stuck timeline
- Removed exec context to emit EStateTreeUpdatePhase::TickStateTree scope, to allow cleaner logs for parallel STs
[CL 33030889 by mikko mononen in ue5-main branch]
- Added icons and icon colors for ST nodes
- Implemented icons for some common ST nodes
- Small update to ST logic icons
- Added icons to the task list in State treeview row, adjusted task list BG color to make icons visible
- Fixed ST editor tabs icons and names (e.g. there were two tabs that had the same label)
- Moved ST node picker to separate class
- Moved category array customization to common helper function
- Added node icons to the ST node picker
- Add node button is not node selector too (simila to Niagara)
- Consolidated the add button style across all lists
- Cleaned up the node customization
- Moved type selector, debug, and property controls into one menu at right
- The combined menu can be also summoned using right click
- Renaming now has to be triggered via the menu
- Replacing node happens via menu
- Most of the row was left "clickable" to later use it for selection
- Improved the visualization and controls for the expression indentation
- Cleaned up state customization
- Moved parameters to own category (similar to the tree params)
- Moved event to the enter conditions category
- Cleaned up transition customization
- Improved the transition display
- Consolidated add button styles
#jira UE-180608
#rb Juan.Portillo, Mieszko.Zielinski
[CL 33030431 by mikko mononen in ue5-main branch]
- Added a new option for selecint child at uniform random in StateTreeStateSelectionBehavior
- Added RandomStream in StateTreeInstanceData and relevant APIs to get stream and set seed
#rb mikko.mononen
[CL 33006455 by jacob wang in ue5-main branch]
Add validation warning if the state tree is not compiled to prevent uncompiled state tree to be submitted
#rb mikko.mononen
[CL 33001894 by guillaume arruda in ue5-main branch]
- When transitioning to a subtree directly, self host the parameters
- Made transitioning to a subtree directly a warning, may make it an error in future versions
#jira UE-211189
#rb Yoan.StAmant
[CL 32969399 by mikko mononen in ue5-main branch]
- Added support for shared event buffer, so that multiple instance data can use the same
- Added API to consume events
- Removed double buffering from events
- Treat TriggerTransitions() as event handler (events flushed after each call to the method)
- Event handlers (including tasks) are executed in priority order
- Transitions and event capturing states can consume events on successful selection
- Added API to tick a StateTree in two passes (update tasks and trigger transitions)
- Change parallel tree tasks to do the task update in Tick(), and event handling in TriggerTransitions()
- Small improvements to the ST debugger to display events
- NOTE: this is breaking change for implementations that has relied events emitted during tick to be available on next EnterState()
#okfirgithub public
#rb Yoan.StAmant
[CL 32924765 by mikko mononen in ue5-main branch]
