#tests Editor details panel with locally built binaries for UEFN, UEFN PIE and VersePrototypes using a combination of optional creative_devices (code as suggested in FORT-77563) as well as verse objects not based on creative devices, arrays of optionals and single optionals tested. "PreSubmitTest.py --linuxmode skip" run.
#rb jared.cotton
[CL 35857311 by kristoffer jonsson in ue5-main branch]
#rb Steve.Robb
#jira UE-221511
[RN] UStructs above 16.7mb will trip an ensure in the Editor so that they remain compatible with upcoming changes to Max ElementSize. You can disable the ensure with CVar CoreUObject.EnsureAgainstLargeProperties.
[CL 35434186 by jodon karlik in ue5-main branch]
* Avoid duplicate work in GetValueBaseAddress for FItemPropertyNode, this function is recursive, the duplicate work branches the recursion and can be expensive for deeply nested property node trees.
* Reimplement calls for GetOwnerPackages and GetInstacesNum for StructurePropertyNode without using GetInstances() - these functions are called from InstancedStructProvider's EnumerateInstances already and cause exponential walk up the property tree
#rb mikko.mononen
#jira UE-207555
[CL 33428738 by logan buchy in ue5-main branch]
[FYI] marshall.beachy
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 33319481 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 33242716 by logan buchy in ue5-main branch]
[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]
* 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]
Add's support for `[at]editable` on optionals:
`FOptionalProperty` changes:
- Added custom `__INIT__` logic for `FOptionalProperty::ExportText` which previously could output no text as the optional value was initialized but returned an empty string as its export text (ie: empty arrays, maps, sets, etc). This caused the future text imports to be incorrect.
`FPropertyNode` changes:
- Added `OptionalValueNode` as private member similar in idea to existing `PropertyKeyNode`. It stores the generated `FPropertyNode` for a FOptionalValue's Value when it is set.
- Added helper function `GetOrCreateOptionalValueNode` which either returns the existing `OptionalValueNode` OR creates one if appropriate.
- Note: This is where we bind a lambda to our Optional's Value FPropertyNode's `RebuildChildren` event which is how we update/rebuild when needed. In places where we would update/rebuild we instead call our Value to do so instead if set and then update after that has been done via this callback.
Added new widget `SPropertyEditorOptional`
- This either:
- shows a dropdown of "Set all" or "Unset all" if we have multiple values selected
- generates the editor for whatever our set value is if we have a single value (See `GetSingleReadAddress`)
- shows a 'set value' button if we are not set
#JIRA UE-191200
#rb karen.jirak
#rb kurtis.schmidt
[CL 28253719 by jared cotton in ue5-main branch]
- Added IStructureProvider which allows to edit multiple instances of structs at a time
- Improved default value handling in standalone structure nodes
- Fixed bug where expanded nodes did not retain their expansion state when structure nodes were rebuild (e.g. when editing a component)
- Removed caching from Instanced struct customization
#jira UE-172047
#rb Jamie.Dale, Adrien.Logut
#preflight 644a48360f12404fb77173f6
[CL 25214019 by mikko mononen in ue5-main branch]
We already had a ParentNodeWeakPtr that we were checking to make sure the pointer was valid - now we just use that value directly instead.
#review-20890479 @lauren.barnes
#rnx
#preflight 62bef0445d53ca5bcea7785a
[CL 20913710 by sebastian nordgren in ue5-main branch]
This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
The core mistake here seems to have been assuming that GetReadAddress() returned false on failure, but in fact it returns false if the values differ. The original implementer may also have thought that setting CanBeExpanded to true would always show the expander arrow, but this is only the case if the node has children.
#jira UE-111980
#rb paul.chipchase
#ROBOMERGE-SOURCE: CL 15859878 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15859882 by sebastian nordgren in ue5-main branch]
The Favorites category is now always visible, and displays a note about how to add properties there when empty.
#rb chris.gagnon
#jira UETOOL-2769
[CL 15208242 by sebastian nordgren in ue5-main branch]
#rb Matt.Kuhlenschmidt
[FYI] Matt.Kuhlenschmidt
#ROBOMERGE-OWNER: nick.darnell
#ROBOMERGE-AUTHOR: nick.darnell
#ROBOMERGE-SOURCE: CL 11358089 via CL 11358143 via CL 11358189
#ROBOMERGE-BOT: (v654-11333218)
[CL 11358651 by nick darnell in Main branch]
