I wrote OpenGL live wallpapers for Android that use 17 pixel and 17 vertex shaders. On my HTC Legend, it takes about 3 seconds to download and compile. Download time is about 20% of this, the rest are compiled.
Live wallpapers have an OpenGL context, every time a full-screen application is launched, and when the wallpaper becomes visible again, all shaders, textures, etc. should be rebooted, as a result of which the screen will freeze for about 3 seconds each time, which is unacceptable to me :(
I did some reading and it seems impossible to precompile the shaders. What else can I do to fix this? Is it possible to load and compile shaders in a background thread? In this case, I could show some animation of progress. It would not be great, but better than nothing ...
[EDIT1] Another big reason to speed it up is that the entire OpenGL-based Live Wallpaper lifecycle is hard to work on all devices (and this is an understatement). Representing long loads when the context is lost / recreated, more headaches are added than I want. Anyway:
As answer 1 shows, I tried to look at the GL_OES_get_program_binary extension to make some kind of compileable one-time compiled-version-per-installed application, but I'm worried about how widely this extension is implemented. For example, my Tegra2 powered tablet doesn't seem to support it.
Other approaches I'm considering:
1) Ubershader: puts all pixel shaders in one large shader using switch or if statements. Will it drastically slow down pixel shaders? Will it change the shader too big and make me overtake all these suspicious restrictions on registration / counting commands / textures? Same idea for vertex shaders. This will reduce my entire shadercount to 1 pixel and 1 vertex shader and hopefully make compilation / linking of batches faster. Has anyone tried this? [EDIT2] I just tried this. Not. Compilation / linking now takes 8 seconds before giving up with the undefined error "link failed" :(
2) Poor loading of the human background: do not load or compile the shaders at the beginning, but download / compile one shader to update the frame for the first 17 frames. At the very least, I would refresh the display, and I could show a progress bar so that the user sees that something is happening. This will work well on slow devices, but on fast devices it will probably make the entire shader load / compile phase slower than it should be ...