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
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.
…look what’s in the pipe from Sam on Processing4:
@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,
Thank you @sampottinger!
For the record, I tried Python mode on Linux and it worked
I’ll try to test it further!
Hey @sampottinger, just got your latest release to run on Manjaro Arm (64 bit on RaspberryPI4 4gig RAM).
What I did to get it to work:-
I downloaded the aarch4 linux zip, and unzipped in my home directory. 2020-04-26_22-59-00_linux_aarch64.zip
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
More experiments to follow…
Installed toxiclibs library and ran this sketch:-
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.
I set up my RPi 4 with a 64-bit kernel and an SSD root drive thanks to these instructions: https://www.jeffgeerling.com/blog/2020/im-booting-my-raspberry-pi-4-usb-ssd
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!
Got another community build at https://www.datadrivenempathy.com/processing! A few more PRs are making their way in.
The work you are doing is appreciated.
On a positive note…
It handles binary literals much better.
It’s Processing’s pre-processing which dunno about binary literals.
We can use binary literals on a “.java” tab even on P3.
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
[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)
And processing runs just fine.
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!