That’s good to know. The LWJGL backend actually doesn’t seem to offer much performance improvement, although there are a few things that could be improved in it. It might still be a good choice based on more active development, but that remains to be seen - it’s good to see JOGL development picking up.
I wonder what are your thoughts on abstracting the OpenGL support? I’ve removed JOGL support in processing.opengl and abstracted PGraphics2D and PGraphics3D - only two methods need to be abstract. If JOGL and LWJGL backends were in separate packages / JARs this would allow for easy and transparent support of both, and the option to make one or other the default in future.
@jeremydouglass@sampottinger Good to see it seems to work well on MacOS and Windows. For my propane and PiCrate releases I knew it would work for 64 bit linux and 32 bit RaspberryPI.
Thank you to those who have been trying out the alpha and reporting issues. I really appreciate everything. With that, I’ve been active on github but I apologize for being a little less so on the forums. I think the broader global covid situation may have slowed things a bit but I have been trying to respond to issues filed at https://github.com/processing/processing4/issues as they have come.
As PR review has (understandably) fallen behind, I resurfaced my fork of processing4. I have all of the outstanding bug fixes merged together at https://github.com/sampottinger/processing4. You can try the latest version of that fork at https://www.datadrivenempathy.com/processing. Unfortunately, the official processing4 master and alpha build are almost 4 months behind now so, if you are free to help test things out, the fork may be best until things catch up.
Thanks so much and hope everyone in the community is well,
Sam
Found out the included java is not compatible, so I deleted it and replaced it, with a link to the correct java (that I was already using for my PiCrate application).
ln -sfn /opt/jdk-openjdk /home/tux/linux/work/java
I ran program from console in /home/tux/linux/work ./processing and I was in business. The install.sh doesn’t work properly (should be easy to fix).
For the moment I think Manjaro Arm linux is what to use but with the advent of the 8gig RaspberryPI4, the RaspberryPI OS 64 is now under active development Raspberry Pi 8 giga
For my PiCrate application I modified PGraphicsOpenGL.java to remove Gottfreid Haiders RaspberryPI fixes (I do not recommend using the Legacy Driver, and we do not seem to need his custom shaders for the fake KMS driver). Makes for simpler code and probably a better look.
@sampottinger I think I know why there is the wrong jdk in the aarch64 build, there is mismatch in naming between build.xml linux-arm64 and the Downloader.java linuxarm (what a crazy build system, it must be nightmare to maintain, like @neilcsmith I would highly recommend moving to maven, it is way saner). Also affects jfx install, however that only seems to be available for armv6hf.
After installing OpenJDK 11, and replacing the included x86-64 JDK with the arm64 version, as mentioned in previous posts, I was able to use the Processing4 build (2020-04-26_22-59-00_linux_aarch64.zip) successfully
Tried out some simple sketches of mine and they ran perfectly. Awesome work!
The jdk included with aarch64 release is still the wrong type as I mentioned previously but easily fixed by creating a soft link. Because I’m using Manajaro linux I just link /usr/lib/jvm/default-runtime.
[tux@monkstone ~]$ java --version
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7)
OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode)
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+.
@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.
@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
[0] "bcm2835-isp #1"
[1] "bcm2835-isp #2"
[2] "UVC Camera (046d:0825)"
So [0] & [2] 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 [2] 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)