How do I close the window other than in direct response to user input?

[jameswilddev]

Sometimes after the user opts to close the game you need to keep the render loop running for a little while. The game might be in the process of auto-saving, disconnecting from a server gracefully, or playing a bit of animation.

It doesn't currently seem possible to do this with Silk.NET. Run()'s source code for reference:

Silk.NET/src/Windowing/Silk.NET.Windowing.Common/WindowExtensions.cs

Line 43 in 2e28f47

public static void Run(this IView view)

DoEvents seems used for event-driven input.

DoUpdate and DoRender both set a variable which is used to throw in Reset (called by Close) so I can't poll in there to see whether these background tasks are done and I can close the window:

Silk.NET/src/Windowing/Silk.NET.Windowing.Common/Internals/ViewImplementationBase.cs

Line 175 in 2e28f47

_inRenderLoop = true;

Silk.NET/src/Windowing/Silk.NET.Windowing.Common/Internals/ViewImplementationBase.cs

Line 207 in 2e28f47

_inRenderLoop = true;

Silk.NET/src/Windowing/Silk.NET.Windowing.Common/Internals/ViewImplementationBase.cs

Line 113 in 2e28f47

if (_inRenderLoop)

(I am guessing that calling Close() from another thread is a Very Bad Idea).

[Beyley]

this seems more engine structure related than Silk specific, you should see if your code already has a way to do the logic of "wait to run some function", if so i dont see why that cant be done here, you dont need to hook into the internals of Silk

[jameswilddev]

I'm confused, the problem is that Silk throws if I call window.Close anywhere but an input handler. This appears to be by design but is very limiting.

[Perksey]

That’s odd, can you give the stack trace? Reset should be expected to throw but not Close, the idea being that Close just sets IsClosing and if you don’t overwrite it, the window will close and reset per the normal Run implementation.

[jameswilddev]

Ah so I think I've gotten to the bottom of what's going on here.

DoRender/DoUpdate/etc. all set _inRenderLoop but don't un-set it in the event of an exception being thrown.

That means that the enclosing using statement then disposes the window with the flag still set - which in turn calls reset and raises the exception I've seen here.

Thanks

[Perksey]

Ah nice found, sounds like we ideally need to add a finally block around these functions but it's extremely expensive to do so on a hot path!

I guess exceptions here should be the user's responsibility, but perhaps we should find a way to expose this. Maybe adding error callback?

Lots to discuss @Beyley, but will mark this discussion as resolved in the meantime.