“Processing is an open source programming language and environment for people who want to program images, animation, and interactions. It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool. Processing is developed by artists and designers as an alternative to proprietary software tools in the same domain. (www.processing.org)
Hanno Wendt and Sebastian Mancke of Tarent ported Jalimo to Openmoko, and then ported Processing to this environment. John Lee has been continuing this work and has the following to report:
Hi,
A brief status report about the current status of ‘Processing’ on neo.
* What is Processing?
Check http://www.processing.org/ . It’s a popular language among designers. It’s simplified java with its own java libraries. User app will be translated back to java before execution.
* Why?
We want to make neo designer friendly.
* Target
To make it run nicely on neo. Originally it runs (with a lot of errors) but it’s extremely slow.
* What have I done:
- tracing it. It brought me to different places such as java awt, classpath, cairo, xrender and x. quite time-consuming.
- doing experiments:
- helloworld in java: 3 secs
- helloworld in processing: 10 secs
- paint 200×200 with dots: 2:05
- paint 200×200 with floating point calculation: 2:25
- paint 200×200 with hacked SDL backend: * 10 secs. *
( just a proof of concept. ignore most features. not usable. )
- profiling:
- gprof failed because of dlopen.
- jvm -Xprof failed because CACAO doesn’t support it on arm.
- oprofile gives usable results.
- trying to improve it
- profiling indicated that the bottleneck was cairo. An upgrade to 1.6.4 makes quite flat distribution so there’s no obvious enemy now.
* What will I do:
The initialization of the jvm + java libraries is quite time-consuming. I’ll try to launch a processing ‘daemon’ in the background and load processing apps as external jar files.
* Call for help:
This issue is quite complex because it involves the performance of jvm, classpath, cairo and xserver. Also the hardware limitations such as 1) no FPU and 2) narrow bandwidth on gta02 make the situation even worse. Any help, suggestion, pointing direction will be most appreciated.
* Special thanks to:
jserv and olv for discussion and suggestion.
Regards,
John
Filed under: Freerunner, openmoko | Tagged: openmoko
Hi Michael, hi John,
concerning the Startup speed of applications:
1. Robert (our main jalimo hacker) is currently on implementing a JIT-Cache, which is able in caching the JIT-Code of the cacao (usable during runtime and build time). This will improve the startup speed a lot.
The JIT-cache implementation is already grown very far, so it may be an opportunity for the “near future”.
2. We are also very interested in a generic Java Startup deamon, running multiple applications, in Jalimo (for all platforms). Most suitable with dbus interface. So, maybe er can cooperate on this!
–Sebastian
Reading this I wonder if we can turn the FreeRunner into an oscilloscope?
http://blog.makezine.com/archive/2008/07/cheap_oscilloscope_built.html
Hi,
Concerning the java-startup problem,
i would suggest a completely different approach wherever applicable:
Start once an OSGi container and then install and start everything inside it, as an OSGi-bundle.
Kostis