Vispy on Android
126 views
Skip to first unread message
Alexander Taylor
Jul 29, 2015, 7:14:51 PM7/29/15
to vispy-dev
I've mentioned a couple of times that I recently got Vispy working on Android (screenshot at http://imgur.com/ojJPWqdu). To avoid derailing the compiler infrastructure thread, I'll summarise here what was involved and what needs further work. I also talked about it a bit at http://inclem.net/2015/07/18/kivy/python_for_android_revamped/ , if anyone is interested in the surrounding python-for-android context.
This works because I recently rewrote Kivy's python-for-android build tools to (amongst other things) support multiple types of java backend, in particular a new SDL2 backend to replace Kivy's old Pygame one. Since SDL2 itself handles most of the Android platform stuff, Vispy's own SDL2 backend works without modification as the window provider.
gloo also works without modification because python-for-android actually successfully builds ctypes, and it worked perfectly once I fixed a hack at our end that prevented it finding libGLESv2.so. We also already supported numpy on Android, and although I hadn't previously tested it much it seems to work fine.
I did have to make two changes in vispy itself. The first disables fonts, as vispy defaults to freetype (sys.platform == 'linux[something]' on Android), but this is probably easily fixed - we actually support freetype itself on Android, though I haven't tested it and it isn't yet ported to the SDL2 toolchain, or failing that I think it should be possible to use SDL_ttf. The second change was to force vispy to use GLES by default, which I think might be a small bug as it always tries to load normal GL first which will crash. I'll check this later and submit a fix if I got that right, and if it isn't fixed in master. My simple patches are listed at https://github.com/kivy/python-for-android/tree/revamp/pythonforandroid/recipes/vispy - they're very crude, not intended as final ways to fix things.
When actually running on Android everything seemed to work fine, but there was huge input lag for scenes although gloo itself was fine (e.g. the rotating cube isn't slow). I guess this is vispy's normal python slowness discussed elsewhere, exaggerated by the slowness of the arm cpu and possibly of numpy since it's compiled without linking to a system lapack or anything (not sure if this matters to vispy). This might already be fixed by the big PR-in-waiting, but it had some small issues preventing me testing it when I tried.
In terms of Vispy being generally usable and useful on Android, the major issue is the slowness, which is hopefully being actively addressed as above. Both things I patched require at most some small fixes in order to work fine. Of course it would also be important to add e.g. basic gesture support beyond the touch rotation that already seems to work, but this obviously isn't a major barrier.
If anyone wants to try making Vispy APKs, it *should* work as described at http://inclem.net/files/p4a_revamp_doc/ by simply using `--requirements=vispy` instead of referring to kivy, but this doc is preliminary and this revamped tool is under active development and hasn't been tested much. I've only tested on Linux, OS X should work too, Windows will work with limited options once I add basic binary distribution. I intend to come back to fix the Vispy target up when I've fixed everything currently preventing Kivy from switching to this toolchain. If you do try and have any problems, let me know and I'm happy to help.
This works because I recently rewrote Kivy's python-for-android build tools to (amongst other things) support multiple types of java backend, in particular a new SDL2 backend to replace Kivy's old Pygame one. Since SDL2 itself handles most of the Android platform stuff, Vispy's own SDL2 backend works without modification as the window provider.
gloo also works without modification because python-for-android actually successfully builds ctypes, and it worked perfectly once I fixed a hack at our end that prevented it finding libGLESv2.so. We also already supported numpy on Android, and although I hadn't previously tested it much it seems to work fine.
I did have to make two changes in vispy itself. The first disables fonts, as vispy defaults to freetype (sys.platform == 'linux[something]' on Android), but this is probably easily fixed - we actually support freetype itself on Android, though I haven't tested it and it isn't yet ported to the SDL2 toolchain, or failing that I think it should be possible to use SDL_ttf. The second change was to force vispy to use GLES by default, which I think might be a small bug as it always tries to load normal GL first which will crash. I'll check this later and submit a fix if I got that right, and if it isn't fixed in master. My simple patches are listed at https://github.com/kivy/python-for-android/tree/revamp/pythonforandroid/recipes/vispy - they're very crude, not intended as final ways to fix things.
When actually running on Android everything seemed to work fine, but there was huge input lag for scenes although gloo itself was fine (e.g. the rotating cube isn't slow). I guess this is vispy's normal python slowness discussed elsewhere, exaggerated by the slowness of the arm cpu and possibly of numpy since it's compiled without linking to a system lapack or anything (not sure if this matters to vispy). This might already be fixed by the big PR-in-waiting, but it had some small issues preventing me testing it when I tried.
In terms of Vispy being generally usable and useful on Android, the major issue is the slowness, which is hopefully being actively addressed as above. Both things I patched require at most some small fixes in order to work fine. Of course it would also be important to add e.g. basic gesture support beyond the touch rotation that already seems to work, but this obviously isn't a major barrier.
If anyone wants to try making Vispy APKs, it *should* work as described at http://inclem.net/files/p4a_revamp_doc/ by simply using `--requirements=vispy` instead of referring to kivy, but this doc is preliminary and this revamped tool is under active development and hasn't been tested much. I've only tested on Linux, OS X should work too, Windows will work with limited options once I add basic binary distribution. I intend to come back to fix the Vispy target up when I've fixed everything currently preventing Kivy from switching to this toolchain. If you do try and have any problems, let me know and I'm happy to help.
Alexander Taylor
Jul 29, 2015, 7:18:15 PM7/29/15
to vispy-dev, alexander...@gmail.com
...messed up the screenshot url, it should be http://imgur.com/ojJPWqd
Eric Larson
Jul 29, 2015, 8:50:08 PM7/29/15
to visp...@googlegroups.com
That's excellent. I wonder if we could have it autodetect which version of `gl` to try to load.
Regarding fonts, it would be great if we could stick with FreeType so we don't have to write another branch of code to deal with font rendering, but at the end of the day the requirements are not too complex (enumerate fonts, load a glyph from a font) so if we have to use SDL_ttf we can.
I hope that the scenegraph-update branch does speed things up a bit. There are additional speedups that we have in mind, too, including combining transforms that are unlikely to change, which could help.
Eric
--
You received this message because you are subscribed to the Google Groups "vispy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vispy-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vispy-dev/eaae4616-019e-430f-9029-9f65b2c6d1ba%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages