'Processing' status report

John Lee john_lee at openmoko.com
Fri May 23 11:00:39 CEST 2008


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 extreamly 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 200x200 with dots: 2:05
  - paint 200x200 with floating point calculation: 2:25
  - paint 200x200 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



More information about the openmoko-devel mailing list