Summary
Dynamic TextBlock content rendered through a World-Space UWidgetComponent under TSR shows stale glyph history after SetText. Two blank frames suppress most of the previous-glyph ghosting, but the replacement glyphs then require several frames to converge to their final appearance. The issue reproduces in Standalone with both Arabic and English text.
What Type of Bug are you experiencing?
Rendering (Graphics / Niagara)
Steps to Reproduce
-
Create a UMG Widget containing a high-contrast TextBlock.
-
Display the Widget through a UWidgetComponent configured as:
- Space = World
- Draw Size = 800x450
- Blend Mode = Transparent
-
Use TSR as the anti-aliasing method.
-
Use a translucent Widget3D material rendered in the After DOF translucency pass.
-
Run the project in Standalone mode and allow the initial text to remain visible until it is fully stable.
-
Replace the TextBlock content at runtime using SetText with a visibly different string.
-
Observe the text immediately after the replacement and during the following frames.
-
Repeat the transition several times between two different strings.
The artifact also reproduces when using English text instead of Arabic text.
Expected Result
When TextBlock content is replaced at runtime, the previous glyphs should disappear immediately and the new glyphs should render cleanly at their final visual density.
The transition should not retain visible history from the previous text, and the replacement text should not require multiple frames to converge to its final appearance under TSR.
Observed Result
When SetText replaces the current TextBlock content under TSR, remnants of the previous glyphs remain visible for several frames, producing a temporal overlap / ghosting artifact.
If the TextBlock is hidden for two consecutive frames before displaying the replacement text, almost all stale previous-glyph history is removed. However, the replacement glyphs initially appear lighter or partially resolved and then progressively converge to their final visual density over the following frames.
The behavior is repeatable when switching back and forth between previously displayed strings and also reproduces with English text.
Changing to FXAA or rendering the widget After Motion Blur removes the temporal ghosting, but introduces unacceptable aliasing. Lowering r.TSR.ShadingRejection.SampleCount also significantly reduces the convergence time, but this is a global TSR setting and is not suitable as a local solution for one World-Space Widget Component.
Affects Versions
5.7
Platform(s)
Windows
Additional Notes
Additional technical context:
Engine: Unreal Engine 5.7.4
Build: 51494982
Branch: ++UE5+Release-5.7
Platform: Windows / PCD3D_SM6
Test mode: Standalone
Resolution: 1920x1080
Motion Blur: Disabled
Production AA: TSR
Relevant Widget Component configuration:
- Space = World
- Draw Size = 800x450
- Blend Mode = Transparent
- Manually Redraw = false
- Redraw Time = 0.0
Current best local material test:
- Translucent
- After DOF
- Output Depth and Velocity = true
- Velocity From Depth Only = false
- Temporal Responsiveness = 1.0
- Responsive AA = enabled
TSR visualization tests using r.TSR.Visualize 0, 2 and 3 showed the changed glyph pixels undergoing history rejection / clamp behavior and rebuilding accumulated temporal samples after the text replacement.
A controlled test of r.TSR.ShadingRejection.SampleCount produced a clear correlation:
- 2.0 = baseline behavior
- 1.0 = noticeable improvement
- 0.5 = further improvement
- 0.25 = substantially faster convergence
These lower values were used only diagnostically and were not adopted because they globally affect TSR.
I would like to determine whether this is expected behavior for dynamically changing World-Space UMG content under TSR, or whether there is an engine-supported local mechanism to invalidate or strictly reject stale history for changed widget pixels without globally weakening TSR.
I would also appreciate clarification on whether UE 5.8 / 5.8.1 contains relevant changes for this case, particularly around Temporal Responsiveness, history rejection, or Thin Geometry handling.
A minimal reproduction project, TSR visualization captures, and comparison videos can be provided if required.