Finally got round to testing ManjaroARM with my RasberryPI3B+ by using same SD card I had used on my RaspberryPI4, and it works well. Here is sketch using my LSystems library, running from processing ide on RaspberryPI3B+.
Glad to see these updates! Thanks for continuing to test this out.
@sampottinger What if any are the implications for processing, when macOS/AArch64 lands, it is clear that Apple have little interest in supporting java and there’s the crazy business of Microsoft offering to help to contribute to the jdk port I know Charles Nutter is keen to do what he can to support JRuby on the platform.
Hey there! For Processing 3, it’s hard to say… Java 8 might get stuck per the conversation at https://github.com/AdoptOpenJDK/openjdk-build/issues/1922. That said, I would expect us to be able to keep Processing 4 afloat: http://openjdk.java.net/jeps/8251280.
This all looks fantastic! I can’t wait to fire up my Pi 4 and give this a try!
@sampottinger @Andres I don’t know whether it’s been solved yet, installing libraries from the ide seems to fail. However I thought I would try the latest video library on the RaspberryPI 4 (so I did a manual install. Using the GettingStarted sketch this is my output on ManjaroArm Linux (64bit)
Processing video library using GStreamer 1.18.0  "bcm2835-isp #1"  "bcm2835-isp #2"  "UVC Camera (046d:0825)"
So  &  seem to be the V4L2 drivers, which may need additional install on Manjaro ARM as well as the camera. However from my previous experience I know  is my USB Camera, so for me at least I should use that (video library defaults to using 1’st in list and that does not work for me). So here’s the modified mirror sketch run from processing ide:-
Installing video library gets as far as creating a folder /home/tux/sketchbook/libraries/library10580665561486927026tmp, but fails to rename it. PS: clicking on updates available seems also to freeze ide.
Hi @monkstone and @sampottinger … Thank you for all your efforts! I make art installations and use RPIs with processing for most of them (trying as low cost as possible). With RPI 3’s phasing out I like to future proof my efforts and go RPI 4. However, as you know, the current stable Processing release doesn’t work well on a RPI 4 (I need to use P2D in full screen). This makes me want to try out your solution of running Processing 4 on RPI 4. However, not quite sure how to get started since I am not a big Linux user… seems from reading this thread, especially @monkstone guidance, the following:
- Install Manjaro. - or Ubuntu desktop (though that requires be to buy 4 GB models)
- Install @sampottinger aarch64
- Replace Java - how / where do you install the correct Java, or is it part of the Manjoro installation?
- Run Processing as usual?
Any additional pointers appreciated … Thanks so much!
@hooeef I have used the SD card from my RaspberryPI4 with Manjaro OS installed, in a RaspberryPI3B+, it works albeit a bit underwhelming, I think it is possible to do a minimal install to save space. You may need to install java see:-
https://linuxconfig.org/how-to-install-java-on-manjaro-linux currently OpenJDK14 is default (which is fine).
I replace java folder (of processing install) with a symbolic link to the distro installed java to use (just link
/usr/lib/jvm/default-runtime , read up on how to create a soft link on unix/linux). PS once you get used to it you may come to love Manjaro which uses Archlinux package management system rather than Debian package management (RaspberryPI OS). The 64 bit RaspberryPI OS is coming, but like a release version of Processing-4.0 it will be a longtime coming.
I am writing this addendum on my RaspberryPI3B+ using said Manjaro install (and the startup time for the processing ide is dreadful if you could avoid using ide on RaspberryPI3B+ you might get better results the ide is a resource hog).
If you are using Sams Release like me then you’ll probably have installed it in your home directory
The actual processing will be in
/home/tux/processing4/work and the java folder will be
Delete or move that folder and replace with symbolic link as described. Once created you should be able to
ls -al in a terminal in the work directory:-
java -> /usr/lib/jvm/java-14-openjdk
java -> /usr/lib/jvm/default-runtime where
default-runtime is itself a symbolic link.
@monkstone your guidance worked like a charm, many thanks!! I can run processing4 now and played with some of the libraries and examples. Figuring out my way around Manjaro (trying to get a virtual terminal running to the RPI 4) but should be able to give my work a go tomorrow. Thanks again!
Not sure how significant or helpful this will be / is, but I briefly tried the pre-built package (2020-07-06_23-54-14_linux_x64.zip) on Ubuntu 20.04 with Unity 7.5.0 (non-standard) and a 4k screen. From my limited testing, it seemed to work fine with only minor issues.
There was an apparent DPI scaling issue on the editor menus where the text was displayed too large. The JAVA2D renderer appeared to have what I assume is the same scaling issues with dimensions not displaying as expected (but I assume that renderer is going away…?).
Screenshots below are 3 vs 4 with a 14pt editor font. The editor font in 4 seems reasonably scaled on my screen, but not the menus. The menus on 3 seem a little strange when compared to Firefox for example, but reasonably sized.
Using FX2D produced the warnings below, but it appeared to not affect the output. IE It looked like anti-aliasing worked fine.
Nov 30, 2020 9:54:56 AM javafx.scene.Scene <init> WARNING: System can't support ConditionalFeature.SCENE3D Nov 30, 2020 9:54:56 AM javafx.scene.Scene <init> WARNING: System can't support antiAliasing
With P3D or P2D I still get the following spew (from JOGL I believe) when closing sketches which has been around for quite a while I think.
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 0, pending (open in creation order): 2) X11Util: Open X11 Display Connections: 2 X11Util: Open: NamedX11Display[:0, 0x7f0924001730, refCount 1, unCloseable false] X11Util: Open: NamedX11Display[:0, 0x7f09241e7d80, refCount 1, unCloseable false]
@rbrauer I have the same spew but the sketch executes okay. However I noticed that my sketch runs faster in fullScreen() - (at 18fps) than fullScreen(P2D) - (at 13fps). That was definitely not the case on a RPI 3 where I can run my sketch in P2D at 30fps. Also when running fullscreen in Manjaro, I still see the “task bar” on the bottom.
I wouldn’t be too surprised to find window issue is with unity desktop, xfce desktop works ok for me with Manjaro Arm.
@hooeef The default task bar option is not to auto-hide, right click on bar (in a blank place) to get menu. Click on
panel preferences set Automatically Hide pane to
@rbrauer - I don’t think this is Unity, but due to UI scaling interaction in newer JDK. I get similar issues with NetBeans on my hi-dpi Chomebook. There are various settings in P4 applied for Windows that should possibly be applied for Linux too by default, and you might want to look at adding in to the preferences.
I see there has been effort in the Processing3 source to try to get DPI from the system but only for Windows so far. I know DPI scaling has always been a mess in Java and everywhere else…
Thanks @neilcsmith, setting the Processing preference for zoom at 200% and launching the PDE (4.x) with “-Dsun.java2d.uiScale=1” makes it look approximately consistent with everything else on my system. I have Unity scaling set at 1.5.
Neither the Processing zoom preference or “-Dsun.java2d.uiScale=1” appeared to change the behavior of the dimensions of the default (JAVA2D) renderer in 4.x as mentioned in my previous post. It seems to create a window with double the dimensions passed to size(…) which doesn’t happen in Processing 3.
Also inconsistent with Processing 3, 4.x sketch windows for P2D / P3D are not automatically centered on screen.
I also noticed on 4.x (even with default settings and no additional command line options on launch) that fullScreen windows for FX2D and P3D / P2D look to be half the size they are supposed to be in both dimensions. Similar to what @hooeef mentioned, the fullScreen window for JAVA2D does not draw over the Unity top bar thing and instead seems to be displaced below it and cut off at the bottom of the screen, but this is the same behavior as Processing 3 on my system.
I’ve released a pre release version of propane (a ruby implementation of processing) which includes latest jogl binaries for ios-arm64. I’m looking for testers (I don’t have any Apple equipment). I know Azul have a jdk11 version for MacOS on arm64.
Hey everyone… it happened! Download \ Processing.org
Great to see! And hopefully Processing style with Java 17 will be an easier transition now. Few additions there that would be really nice in Processing.