Hi,
the only valuable solution I have found is the creation and parenting of a new Widget Blueprint to an existing Widget. While this works as expected, I’m somehow concerned about the Overhead. For my current needs this work flow would be acceptable, but for large journals or chatlogs this definitely will be a bottleneck. As of now I have tested this for 10k instances which create 20k Blueprint calls.
So my question is, if there are different approaches to Dynamic Widgets beside parenting and/or if there are plans for alternative solutions in the near feature.
Hmmm, can’t you update the contents of a widget instead of spawning numerous ones? Btw, what do you mean by 10k instances? 10k child widgets?
Updating content is only of very limited use, for limited use cases. In general updating content is useful when you want to replace existing content, but if you want to add new content to the existing content you run into numerous dead ends very quickly. As example for text you have terrible layout/style control, and image, buttons or anything else is just impossible to add by updating. In addition it’s also a very bad workflow, of course, there are certainly exceptions.
Yes I mean I attached up to 10k child widgets on runtime. The good news is, if you can pause the rest of the game during the widget being active it’s still working relatively well on a strong cpu with that many entries. The bad news is, if you have for example a chatlog with 250 entries and open that while playing you will definitely suffer from a noticeable fps drop.
But anyway regardless of my tests, it just feels wrong to create a completely new widget blueprint and parent it to an existing one, rather than just create new widgets for an existing blueprint. Well, I surely can live with that, if theres no different approaches or upcoming engine improvements. But if there is, I rather know now before I implement functions to overcome the restrictions of the current solution.