The issue here is that the derived destructor for FFeedbackContextEditor would destroy it's TWeakPtr<SWindow>, proceeded by the destruction of any remaining FScopedSlowTasks held in the LegacyAPIScopes array. This destruction may have caused FFeedbackContextEditor::FinalizeSlowTask to be called which could have resulted in the TWeakPtr being used after its RefereceCount was deleted, causing a memory overwrite. I can't see any code in the wild which could have caused this, but I've also added some additional safety checks to catch error conditions earlier.
[CL 2605382 by Andrew Rodham in Main branch]
This should prevent it from grabbing the foreground window when running in the background.
This addresses UE-10994.
[CL 2489113 by Andrew Rodham in Main branch]
There was a potential vulnerability where a slow task widget would not get cleaned up resulting in it outliving the pointer to the scope stack. The context no longer holds a strong reference to the slow task widget in a bid to prevent it from outliving the data to which it is tied.
[CL 2455914 by Andrew Rodham in Main branch]
Editor startup splash improvements
- Splash screen now updates with loading activity more frequently
- Cleaned up the game name and version text
- Cleaned up loading activity animation look a bit
- Removed 32-bit/64-bit from splash. The editor is always 64-bit.
- We now display the game name after the editor version
[CL 2446998 by Matthew Griffin in Main branch]
Fixed slow tasks sometimes not updating their progress dialogs
SlateTick was being throttled along with slow task progress updates
[CL 2425815 by Ben Marsh in Main branch]
Introduces the concept of "Active Ticking" to allow Slate to go to sleep when there is no need to update the UI.
While asleep, Slate will skip the Tick & Paint pass for that frame entirely.
- There are TWO ways to "wake" Slate and cause a Tick/Paint pass:
1. Provide some sort of input (mouse movement, clicks, and key presses). Slate will always tick when the user is active.
- Therefore, if the logic in a given widget's Tick is only relevant in response to user action, there is no need to register an active tick.
2. Register an Active Tick. Currently this is an all-or-nothing situation, so if a single active tick needs to execute, all of Slate will be ticked.
- The purpose of an Active Tick is to allow a widget to "drive" Slate and guarantee a Tick/Paint pass in the absence of any user action.
- Examples include animation, async operations that update periodically, progress updates, loading bars, etc.
- An empty active tick is registered for viewports when they are real-time, so game project widgets are unaffected by this change and should continue to work as before.
- An Active Tick is registered by creating an FWidgetActiveTickDelegate and passing it to SWidget::RegisterActiveTick()
- There are THREE ways to unregister an active tick:
1. Return EActiveTickReturnType::StopTicking from the active tick function
2. Pass the FActiveTickHandle returned by RegisterActiveTick() to SWidget::UnregisterActiveTick()
3. Destroy the widget responsible for the active tick
- Sleeping is currently disabled, can be enabled with Slate.AllowSlateToSleep cvar
- There is currently a little buffer time during which Slate continues to tick following any input. Long-term, this is planned to be removed.
- The duration of the buffer can be adjusted using Slate.SleepBufferPostInput cvar (defaults to 1.0f)
- The FCurveSequence API has been updated to work with the active tick system
- Playing a curve sequence now requires that you pass the widget being animated by the sequence
- The active tick will automatically be registered on behalf of the widget and unregister when the sequence is complete
- GetLerpLooping() has been removed. Instead, pass true as the second param to Play() to indicate that the animation will loop. This causes the active tick to be registered indefinitely until paused or jumped to the start/end.
[CL 2391669 by Dan Hertzka in Main branch]
FScopedSlowTask has been refactored to better allow for nesting of slow operations. This allows us to cascade nested scopes and provide accurate feedback on slow tasks. FScopedSlowTasks now work together when nested inside sub functions. Break up long functions that contain calls to multiple nested FScopedSlowTasks with FScopedSlowTask::EnterProgressFrame().
Example Usage:
void DoSlowWork()
{
FScopedSlowTask Progress(2.f, LOCTEXT("DoingSlowWork", "Doing Slow Work..."));
// Optionally make this show a dialog if not already shown
Progress.MakeDialog();
// Indicate that we are entering a frame representing 1 unit of work
Progress.EnterProgressFrame(1.f);
// DoFirstThing() can follow a similar pattern of creating a scope divided into frames. These contribute to their parent's progress frame proportionately.
DoFirstThing();
Progress.EnterProgressFrame(1.f);
DoSecondThing();
}
This addresses TTP#338602 - NEEDS REVIEW: Editor progress bars nearly always just show 100%, don't offer useful indication of progress
[CL 2322391 by Andrew Rodham in Main branch]
#ttp 337654 - EDITOR: Pressing Escape does not stop autosave
#branch UE4
#note The underlying issue appears to be that Escape should no longer cancels slow tasksà At around CL#1892733 a dedicated (optional) æCancelÆ button was added which is meant to be shown when the user is allowed to cancel the task. Unfortunately, autosave occurs in a common place where itÆs not always appropriate to cancel, so enabling Cancel to occur on the slow task by default wasnÆt a viable option. To get around this I modified the slow task so that Cancel can be toggled on or off at any point during its existence, depending on the context of the task at hand.
#add Added new function to FFeedbackContext: EnableUserCancel, so the user can manually show/hide the cancel button at any point during a slow task û this is handy when dealing with multiple jobs not all of which support the ability to cancel.
#change Tidied up SSlowTaskWidget by removing duplicate code and modifying how OnCancelClickedDelegate is used.
#remove Removed æEscapeÆ message now that cancel button is present.
reviewed by Thomas.Sarkanen
[CL 2217501 by Andrew Brown in Main branch]
#TTP 338368 - EDITOR: CRASH: Div by zero in FFeedbackContextEditor::UpdateProgress() called from FSimplygonMeshReduction
#branch UE4
#proj Editor.UnrealEd
#change Defaulted the Saved and New Ratios to 0, then tested the divisors for > 0. Added an ensure onto the passed in devisors check, if the user is passing in 0 they should be notified as they are using the interface wrong.
#reviewedby Chris.Wood
[CL 2119580 by Barnabas McManners in Main branch]
