Don't know, probably not. The reason that happens at all is because Windows itself pauses the message pump thread when the window is changing. When I find some time I'll put that in a separate thread to prevent it.

Guess that hasn't been implemented. Open an issue on GitHub please. Meanwhile give the android-native backend a try, that should get rid of your black bar.

android or android-native target?

That doesn't sound like a CPU bound test at all. Change the resolution, see what that does to the frame times.

Sorry, no idea why that is. JavaScript performance can sometimes be surprising but did you verify both variations really follow the exact same code paths? And is your scene even CPU bound?

Not sure it still works, I put that in years ago and nobody ever cared. It should output a shader which ends up in the Shaders class and can be used like any other shader.

ok, so it's intel graphics after all. It seems to be something about the init code at https://github.com/Kode/Kore/blob/master/Backends/System/Linux/Sources/Kore/System.cpp#L108 that intel doesn't like but I don't know what it is.

Aha. We had one other guy having a problem like that but I can't reproduce it. But he is running on integrated graphics, are you sure your installation uses your dedicated graphics?

Addendum to make it more clear:
Audio1 is a high level audio API, which has a software implementation in Kha which is used if possible (that's the mixer).
Audio2 is a low level audio API which always talks to a system API as directly as possible. This uses Kore's audio API directly when you use a C++ target in Kha.

When you use a C++ target, Kore is used as Kha's backend for everything, including audio. Kha still does audio mixing itself, maybe that's what got you confused.