Slate Drag & Drop operation : transparent images result in images displayed from prior operations


I’m writing a plugin for UE4 and have been implementing a drag & drop mechanism by inheriting from class FDragDropOperation.
The operation itself works as intended: widgets can receive the operation, I can drag it around etc.

However, there is a visual bug going on: after having dragged an image around, a second drag of a different image will result in having the previous image(s) displayed under the current image.
Here is a gif showcasing the problem:

It works the same the other way around. I have debugged the widget’s image content, and it’s always the correct one and there is only a single image available.
To me, it seems like the window being used as a mouse decorator in the first drag & drop gets cached in some way and the new image of the new operation is laid on top.

Here is a screenshot of the relevant code

Might an underlying Slate bug or design issue be the problem here? Because as far as I can tell, through debugging etc., every new drag & drop operation creates a new drag and drop object, which in turns has an FSlateBrush object called brush, which gets instantiated with the eventIcon UTexture2D pointer of the respective dialogue event.

So basically, in pseudocode:

Start drag & drop:
Create operation
Create brush from texture
Add image to window that uses brush
On drop: destroy window and operation

Since this is a rather complex topic I’d rather ask on the forums than on the Q&A hub; maybe this is by design and I shouldn’t use something with transparency.

Small update: I managed to do a workaround that doesn’t quite fix the issue, by painting an SColorBlock under my actual image. This way, the “cached window” gets overdrawn before I add the new SImage to it. Of course, this results in transparency not being supported, but at least it’s properly useable like this.