widget component size setting having preference over actual widget size setting

hi

why does a widget component size setting in an actor blueprint take precedence over the size setting of the same widget blueprint and node in a blueprint?

i have limited the size of the widget blueprint, and have set the desired size of the widget in a blueprint via set desired size, yet it gives precedence to the size setting in the actor blueprint where the widget is used as a widget component

thanks

If I recall correctly the desired draw size of a widget component in an actor can’t be changed during runtime.

Why exactly? I don’t know, probably very technical. But you’ll have to know at what size you want to draw your widgets beforehand.

A dirty workaround depending on your use case could be to scale the actor itself.

It can, it can even be automated but it’s somewhat expensive to call it every frame:

Manual size updates and invalidation would shine here. But I’d rather explore the why we need to do this in the first place… In this case you’d need to work-in an additional pre-pass as the thing is glitchy.

why does a widget component size setting in an actor blueprint take precedence

Because it was designed like so - that’s the intended use.

[…] i have limited the size of the widget blueprint

How? Because nothing stops you from having a large component Draw Size with a smaller widget that does not take all the space - too many ways to achieve that. The details of how and why you’re doing this are crucial. And so is the desired behaviour.

The more I know! Is there any reason this would work differently in VR? Trying to adjust the desired render scale in VR caused some weird issues for me recently which is why I assumed you couldn’t do this during runtime.

Hard to tell what you mean without more details. Whether this is VR or not does not matter. It’s a piece of mesh with a texture on it. The component can, optionally, be informed that the underlying widget has changed dimensions, and adjust the mesh size. This is not enabled by default.


Unrelated, merely musing: it may not even be that glitchy. I feel we’re looking at the component being really bad at blurring motion. :person_shrugging: