Ryan Hileman

Another thing to look for - if your process crashes, libgl_remote will stay in the background spinning. Make sure you don't have any of those sitting around.

It's possible to fork an ARM process from exagear: http://boards.openpandora.org/topic/11506-glshim/page-22#entry393842 I did some research and I'm going with pipe() over event_fd, because it's a bit more portable. This means you...

I did some research and local sockets are a bit slower than pipes, so I'm going to stick to pipes for now.

Can you try 93f4557b178b182453f6e90945bffcd3be061392? It's significantly faster to sync in my current tests, so as long as we don't find any race conditions I'll probably keep it.

There's some kind of race condition. I'm working on it.

You're talking about e8f02051403c43bf2b61db597200ac2ea7f8abcf right? You might want to play with the SPINLOCK_YIELD and SPINLOCK_COUNT numbers and see if that helps.

pipe-sync isn't properly using the pipe atm. It needs to hold and pass both the read and write file descriptors to work.

can you check the latest unstable? I merged pipe-sync, though I haven't had a chance to check performance on the new version.

Outright _switching_ to GLESv2 isn't correct, because GLESv2 cannot do all of the operations available in GLESv1 (like [glLogicOp](https://github.com/kripken/emscripten/issues/1416)). GLESv2 will also be slower on some platforms, which is a...

Do you have an example of an app using both shaders and fixed function pipeline?