3.3.6 on ARM & Raspberry Pi: What's New

edited September 5 in Raspberry PI

Processing 3.3.6 is out of the oven. Here's the build for ARM. (The AARM 64-bit build got build while we investigate an issue with the bundled JVM.) Our pre-configured Raspbian image is currently at version 3.3.5.

Processing 3.3.5 ARM-specific changes:

  • Support for Raspbian release August 2017 got silently added to the release on August 21 2017
  • Raspbian image got rebuilt, now based on the same August 2017 release containing Debian Stretch. Get it here.
  • Support for the August 2017 release was also added to the GL Video library in version 1.2.3

Processing 3.3.4 ARM-specific changes:

  • Running Processing with sudo now loads the preferences and sketchbook folder of the original user
  • The OpenCV library now supports ARM devices out of the box
  • Processing's Sound library does so too
  • The GL Video library got updated to version 1.2.2 with these changes:
    • Updated Raspberry Pi & macOS to GStreamer 1.12
    • Revamped the capability parsing code in GLCapture
    • Added a start method to GLCapture for compatibility with the Video library
    • Added a shader-based video mapping example by @Sardtok
    • Compiled native library with -ffast-math

Processing 3.3.3 ARM-specific changes:

  • IO library: waitFor got fixed

Processing 3.3.1 ARM-specific changes:

  • It is no longer necessary to uninstall the libgles2-mesa package on Raspbian - we automatically load the correct implementation depending on whether the experimental driver has been enabled or not.
  • We work around an issue related to multisampling - this makes 11 more P3D examples run with the experimental driver
  • The GL rendering is no longer offset when overscan is enabled
  • The mouseButton value has been fixed (#4499)
  • 64-bit ARM support got added (please holler if it doesn't work)
  • Hardware-accelerated OpenGL now works for ARM Mali devices, such as the CHIP and PocketCHIP
  • IO library: waitForInterrupt got changed to waitFor (throws a runtime error instead of returning a boolean, can be called without timeout argument)
  • IO library: SPI.close() got fixed
  • IO library: the undocumented RPI class got removed (everyone seems to be using GPIO numbers anyway)
  • Sound library: there is a test build of Processing's sound library that should work on ARM boards (please holler if not)

Processing 3.3 ARM-specific changes:

  • Raspbian image got rebuilt, now based on the January 2017 release. Get it here.
  • If you are interested in 3D, make sure to also try out the experimental driver contained in the image. The raspi-config utility can be used to select which of the two drivers is being loaded. (Note: In the most recent Raspbian release, March 2017, the experimental driver has some issues when used with Processing, that's why we're sticking to the January release for now. Feel free to update if you aren't planning on using the experimental Mesa driver.)

Processing 3.2.3 ARM-specific changes:

Processing 3.2.2 ARM-specific changes:

  • loadPixels() now works in combination with the GL Video library (patch by @codeanticode)
  • Processing can now work out of the box with a globally installed JRE copy (e.g. symlinking java to /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/ on Raspbian) - no more reason for font sadness!

Comments

  • Do you know if 3.2.2 made it into the Sept release? I couldn't find a program manifest for the latest Raspbian to confirm it. I've got a RPi3 on the way and I was going to set up the SD card in advance. Cheers.

  • @SiriusCG No, not that I am aware of... you need to install a full Raspbian, get rid of the libgles2-mesa package, and install Proccessing.

    There's also a pre-configured image linked on the Processing Wiki. This will hopefully updated to 3.2.3 in the next day or so.

  • Ah, excellent. Thanks for the information. I may have to do some tweaking anyway. Wolfram and Mathematica have been put on the NOOBS image release and they are being discussed as well as Processing for this project. I'll just wait and see after I get my RPi3 running. Cheers.

  • @SirusCG Best of luck - the pre-configured image w/ the September release should show up here in about an hour or so.

  • @gohai Thank again for the heads up. :)

  • Updated for Processing 3.3.3

  • More updates

  • Updated for Processing 3.3.4

  • Just curious about how the 3.3.6 Raspian 64-bit image is coming along.

  • @SiriusCG The one issue with 64-bit ARM was that it turned out that Oracle's JVM releases for that platform were of the "headless" kind, so they don't include the necessary bits for graphical applications. Unsure why this is this way really...

    It seems that we would have to switch to using OpenJDK for 64-bit ARM, which needs some tooling work and convincing that it's worth the extra complexity. Especially since there isn't yet a Raspbian release that would make use of all this. But it's on the list!

  • Thanks for the update gohai. I agree with you, strange not to have the graphical elements available. One would think, with the profusion of ARM mobile devices, Oracle would continue to provide them. Either way, I'm sure it will all work out.

    Cheers.

  • @gohai - have you looked at Zulu Embedded? Not sure what tooling work you're thinking of? It'll all be OpenJDK soon anyway - Oracle are planning to ship it as standard.

  • @neilcsmith_net Interesting. Have you used Zulu Embedded? Is there any performance or footprint benefit over Oracle on ARM? (License is important but since Raspberry Pi is shipping with Oracle JRE anyway...)

    What I meant with tooling: changing the build files to pull in a different JRE, which might or might not be released in lock-step with the Oracle JRE that Processing is tracking on all other platforms. Convincing Ben to disable the third-party JRE warning (at least on arm64). And then making sure this works and gets good testing coverage (with only a very tiny fraction of the user base needing this).

  • @gohai the key thing was you said current Oracle 64-bit was headless?! I haven't tried Zulu Embedded yet, though plan to in the next few weeks. It's meant to be feature and performance comparable, and with GUI support. I use Zulu with Processing / Praxis LIVE on Windows and MacOS though, and hand it out at workshops if people don't have a JDK. It's a good drop-in replacement. Matching specific versions should be doable - think the version numbers line up these days.

    The warning is going to have to go soon anyway, seen as Oracle will be shipping OpenJDK (as I mentioned) as their free Java option - https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se

Sign In or Register to comment.