PocketMatrix

The code I posted is what my original app looked like. For the GapiDraw one I did place my draw() function inside ProcessNextFrame. You still need critical sections protecting it because in my code above WinProc and draw are guarenteed to not be called at the same time, because the loop is either drawing or posting messages.

But in GapiDrawApplication there is another thread that is created, so WinProc and ProcessNextFrame (which includes my draw) can be called at the same time. This is why my app was crashing, I expect and require that WinProc and ProcessNextFrame be called separate, this is why I need critical sections.

Your suggestions of posting input and handling it later would work fine, it is just a little easier to add 5 lines of code for critical sections, than queing and dequing another message buffer on top of the windows message buffer.

Very true... Multiple queues is unavoidable, with critical sections that follows.

Actually, the best solution would probably be to provide both multitthreaded + singlethreaded GapiApplications.. I'll see what I can wrap up in the next beta...

Thanks for the comments + feedback.

You can use GapiDraw without using GapiApplication.
So if you are porting a single threaded PC game it might require less time if you just use basic GapiDraw.
Johan, perhaps it would be good to more clearly emphasize that GapiApplication is multithreaded in the documentation and the samples. I think that it is really bad if you are implemnting something in a multithreaded system when you think it is single threaded. Now when I come to think of it having a singlethread option might also give you a hint that you are using multiple threads otherwise .