Hi list! I’ve made an experimental backend that allows SDL2 apps to work
under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2 NaCl
port and parts of the SDK code,plus a lot of tears and blood courtesy of
the almost non existent debug support!
Anyway, currently the biggest problem with the port is that it is slow,
VERY slow. This is because NaCl is in essence an event driven single
So, to adapt SDL apps with an endless main loop what the port does is run
it in a thread. This does not seem so bad in principle, however, there’s a
key NaCl limitation: all Pepper API and OpenGL ES2 calls need to happen on
the main thread.
I’ve worked around this limitation by adding wrappers on the SDL_Renderer
functions, which then call the actual functions on the main thread and
block the worker thread until the function is executed, a mechanism that is
fairly transparent to the end user…but as I said, the end result is a
slow app, because the RPC system used for this is inherently slow.
I’ll be happy to hear who else is interested in this backend, ideas on how
to improve speed (I can’t think of nothing else but wait for Google to
allow Open GL calls from threads, or refactor apps with a different main
I was going to make a patch and submit it to the tracker as agreed with
Sam, however I’ll just point you to my experimental repo instead
For a working patch that applies on the official repo I would need to
remove the RenderCopyEx changes, so that will need a bit of work on my
side, work that I would rather not do if there’s not too much traction in
the community on this subject.
I’ll close with an extract of the README file I’ve added at test/nacl
- Requires Pepper 18 or higher
Edit prepare_nacl_env and set the NACL_SDK and optionally the PREFIX32/64
Run buildsdl, this will build SDL for the two versions (x86 32 and 64 bits)
Run buildtest, this will create a basic test based on testspriteminimal.c
Run httpd.py to start the web server
Run runchrome to view the example in Chrome.
- The NaCL backend uses the OpenGL ES2 renderer
- Because all PPAPI and GLES2 calls need to happen on the main thread, SDL
apps will behave slowly…(for now!)
- You can alternatively modify your app to run entirely in the main thread,
thus gaining a speed bump,
the problem with doing this is that you have to retool the main loop to
behave in an event driven fashion
- Fully static linking with the glibc toolchain does not work
- In this example, SDL is statically linked against the example, the NaCl
libraries are dynamically loaded.
- Debug facilities in NaCl are severly lacking, some output is available at