When hit-testable content is contained in a RetainerBox with a non-zero rotation, the hit testing appears to not be taking into account the rotation. Buttons are moused over when the mouse cursor is in the position the non-rotated button would be in, not the location the button is actually in. See attached video file for example of this behavior.
[Attachment Removed]
Steps to Reproduce
Add hit-testable content (e.g. Button) to a Retainer Box, set the transform Angle to a non-zero value on the Retainer Box. Hit testing for the content will be incorrect, not taking the rotation into account.
In the attached sample project, open the level MenuMap and start Play in Editor. Note that the buttons are not highlighted correctly when moused over.
[Attachment Removed]
Hello [mention removed],
Thanks for the reporting this behavior. I can confirm I’m able to reproduce it in UE 5.6, 5.7 and a recent source build from UE5-Main at CL 49899931.
Looking into the engine code, when SRetainerWidget uses a HittestGrid internally:
Args.GetHittestGrid().AddGrid(HittestGrid);The appended hit-test grid is designed for cases where both grids occupy the exact same space. There is currently no transform support at this boundary, so rotation is not accounted for during hit testing.
I’m going to continue investigating this and check with the engine team. I’ll follow up with you once I have more information.
Best,
Francisco
[Attachment Removed]
Hello again [mention removed],
I’ve gone ahead and registered this as an engine bug. You’ll be able to track it here once it becomes publicly visible: https://issues.unrealengine.com/issue/UE\-361595
In the meantime, as a possible workaround, would it be feasible on your end to disable Retain Render on the RetainerBox instances that apply rotation? This should allow hit testing to behave correctly for the rotated widget but at the cost of not using retained rendering for that subtree.
Please let me know if this alternative works for you.
Best,
Francisco
[Attachment Removed]
Hi James,
That public link should be visible now and we’re investigating on our end, though it’s unlikely that we’ll have a quick fix. This seems to specifically be an issue with the retainer widget being rotated, but it does handle it’s internal clip state properly. Perhaps a workaround could be to apply the rotation to some widget within the retainer instead of the retainer itself. Clipping may be a challenge so you’ll need some extra padding between the retainer and the contents to ensure everything is actually within the retainer, but would that be a possible workaround?
[Attachment Removed]
Hi there,
Quick update, we were able to get an experimental fix checked into mainline if you wanted to give it a try. You can find that at CL#50514011, we’ve added a new CVar Slate.EnableRetainedRenderingHittestRemap that is on by default but can be toggled off if it causes any problems.
Best,
Cody
[Attachment Removed]
Hi Francisco,
The ticket isn’t visible yet, I’ll keep an eye on it though- thanks!
Unfortunately turning off Retain Render is not viable for us, because the rotated content becomes strongly aliased without Retain Render on, spoiling the presentation of the UI.
Cheers,
James
[Attachment Removed]
Hi Francisco,
The linked bug ticket is still not visible - is that the correct issue number?
Thanks,
James
[Attachment Removed]
Hello [mention removed],
Yes, that is the correct issue ticket. It can take some time for new reports to become publicly visible while they go through internal review but once it’s published it will appear under that link in the issue tracker.
Regarding the alternatives for this issue, if disabling Retain Render isn’t viable, then an engine-side fix should probably happen in SRetainerWidget::PaintSlowPath so rotation isn’t ignored when data is passed for hit testing. I’ll look more into this and follow up if I find anything useful.
Best,
Francisco
[Attachment Removed]
Hi Francisco,
The Jira still isn’t visible, I was just wondering if there was any update on this? If we can’t get an engine fix we’ll need to change some UI content pretty urgently, so it would be good to know either way so we can plan accordingly.
Thanks,
James
[Attachment Removed]
Hi Cody,
Unfortunately if the rotation is applied on a child widget (rather than on the retainerbox), we still see strong aliasing render artefacts along edges - which makes sense, as the content is still rotated relative to a retained render box which has an unrotated pixel grid. (This is similar to the issues we’ve had turning off the retained rendering.)
Since it seems like it’s not going to be a straightforward fix, we’ll take a look into other ways of mitigating the aliasing on the rotated content, and try disabling the retained rendering. Thanks for the update!
[Attachment Removed]