Forums | NoesisGUI

I realize in other, older (5+ years old) threads, it's made clear that no Noesis calls can occur from outside the original Noesis thread.

I was wondering; has that been considered? Even just being able to touch a ViewModel, and invoke its OnPropertyChanged function, from other threads.

My current setup means all game code is in systems that are executed as jobs across all threads, with my own management of read/write dependencies that eliminates race conditions. This is fine, until I try to interact with Noesis. The approach I'm using at the moment is to subclass NoesisApp::NotifyPropertyChangedBase with my own DeferredNotifyBase, shadowing the base OnPropertyChanged function, changing it to set the value and push the given property name to a thread-safe queue, then when back on the main thread I walk the queue and invoke OnPropertyChanged for each.

This works, but then if I want a system to be able to create a ViewModel and set its properties, it starts getting more complicated. Can I create a ViewModel on another thread? What about pushing to an ObservableCollection (such as creating components, and their respective ViewModels, from systems on different threads?)

It would be amazing if Noesis can buffer this all up and still apply it on a single thread when we call Update, or any other solution to the problem, as game code get increasingly threaded.

Side-question; what are some of the ways others have, in your experience, worked with multiple threads + Noesis? Any patterns that might be useful?

Thanks!

#2256 was created for being able to modify Data contexts from different threads.

Side-question; what are some of the ways others have, in your experience, worked with multiple threads + Noesis? Any patterns that might be useful?

I know a few clients are totally isolating the UI in a thread (so they have Main, UI and Render), serializing the interaction with a queue. But these setups tend to be very complex to maintain and add extra delays in the inputs that are not easy to solve.

#2256 was created for being able to modify Data contexts from different threads.

Side-question; what are some of the ways others have, in your experience, worked with multiple threads + Noesis? Any patterns that might be useful?

I know a few clients are totally isolating the UI in a thread (so they have Main, UI and Render), serializing the interaction with a queue. But this setups tend to be very complex to maintain and add extra delays in the inputs that are not easy to solve.

Yeah fair - I've hit some latencies myself by trying to buffer things up. I might just find a way to mark those UI-touching systems as main thread only, but it's a shame when everything else "just works".

#2256 would be AMAZING. Is that a far future improvement?

#2256 would be AMAZING. Is that a far future improvement?

Yes, the plan is implementing this in 3.2.X, probably after first alpha release of the Studio.