Forums | NoesisGUI

I am using an image brush to render parts of a large monogame render target

This works fine when the render target and brush view box coordinates are not changing, but as soons as the render target or the view box coordinates are updated, Noesis seems to pick the wrong parts of the monogame texture, I think its one frame off.

It seems I can fix this by updating the render target and brush view box coordinates after Noesis has rendered, but that causes an initial flash because the first time the target is empty.

In other applications, ie video processing, one typically uses a semaphore of buffers, buffers being produced and consumed. But that would introduce latency.

I would like to know how to tackle this robustly.

Nevermind, I think I solved the problem.

I'm I correct to assume that Noesis does not have a separate render thread? It has an extra thread for performing tessellation and triangulation, but the rendering itself is done on the main thread, using the Direct3D immediate device context?

NoesisGUI 2.0 does not create any thread under the hood. That's responsibility of the client code. Our rendering architecture is thread-safe. Update() and Render() can be invoked in parallel. Our minimal integration samples don't do it but for example, in Unity we take advantage of that. I think that the MonoGame integration provided by ai_enabled is still single thread although we have privately talked about the possibility of having a render thread.

I think that the MonoGame integration provided by ai_enabled is still single thread although we have privately talked about the possibility of having a render thread.

Yes, because MonoGame is working this way - update (perhaps several times), then draw, repeat. Using a parallel rendering thread is not trivial and will require change of concept of how the drawing code is working for the rest of the game (it should not use mutable state objects, etc multithreading issues). It doesn't make much sense for most MonoGame games as they're fairly simple (2D) and the update thread is not that heavy loaded.
Please correct me if I didn't understood right how it should work without much redone of the engine.
Thought even in case of multithreading l don't understand how it's really related to the issue mentioned by @Ziriax - in case of parallel threads it will be much more likely to draw the outdated state so usually it only increases the input lag on about one frame.


@Ziriax

I'm I correct to assume that Noesis does not have a separate render thread? It has an extra thread for performing tessellation and triangulation, but the rendering itself is done on the main thread, using the Direct3D immediate device context?

As @jsantos told us, there are no extra threads in NoesisGUI, and MonoGame-NoesisGUI integration is done in the most straightforward way. So you need to update your game state (including positions), then update NoesisGUI, then draw your game and NoesisGUI. If you update NoesisGUI before updating your game state then NoesisGUI will use the outdated state (on exactly one frame).

Very interesting, thanks for the detailed info! So my mental model of how Noesis works was wrong, I believed Noesis was like WPF, always sending messages to a DUCE thread that performs the native rendering.

I looked at my code and indeed, I first call , and then I update my game state (that also changes Noesis attached properties). I'll change that order! Thanks @ai_enabled for this tip.

Regarding multiple threads... One thing I would like to do when my app goes into production (it is currently in prototype phase) is display an animating "loading/busy indicator" when Monogame is loading content. That cannot currently be done, since Monogame is single threaded, and blocks. Ideally I would like to have a main thread that runs Noesis, and a second thread that runs MonoGame, rendering all game related stuff into an offscreen render target that is displayed by Noesis.

It seems the Monogame team is taking some steps to run the game loop on a separate thread on UWP https://github.com/MonoGame/MonoGame/pull/5520.

It seems the Monogame team is taking some steps to run the game loop on a separate thread on UWP https://github.com/MonoGame/MonoGame/pull/5520.

Yes, that is the way to go. Having a render thread is very advantageous for noesis to reduce the stress of the main thread. We even have clients with 3 threads: main, ui and render. Besides, our experiments with Direct Composition and NoesisGUi has been very satisfactory.