Processing in style with Java 11

Processing Development
61

@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 / panel preferences set Automatically Hide pane to intelligently.

62

@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.


63

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.

64

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.

65

Hey everyone… it happened! Download \ Processing.org

5 Likes
66

Great to see! And hopefully Processing style with Java 17 will be an easier transition now. :smile: Few additions there that would be really nice in Processing.

67

Hello,

Thank you @sampottinger for your contribution to this!

You are a stalwart!

:)

5 Likes
68

Hello. Not sure if I made a silly error but I’m getting this error in the console of Processing:

core does not run on this architecture: arm64
core is only compatible with the  32-bit download of Processing
  • Running Ubuntu Desktop 21.04 64-bit on RPi4 8GB
  • Installed Linux Processing 4.0b1 from processing.org/downloads and installed in /opt folder
  • Installed JDK with sudo apt install default-jdk
  • Moved java folder in Processing installation folder and applied soft link with sudo ln -s /usr/lib/jvm/default-runtime java
  • Run ./processing and it opened fine but with the below warnings in terminal:
$ ./processing
aleksander@rpi4:/opt/processing-4.0b1$ WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by processing.app.platform.LinuxPlatform (file:/opt/processing-4.0b1/lib/pde.jar) to field sun.awt.X11.XToolkit.awtAppClassName
WARNING: Please consider reporting this to the maintainers of processing.app.platform.LinuxPlatform
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Sep 21, 2021 4:30:52 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
  • Tried a simple sketch and the above error occurred.

I’m a complete beginner, so any pointers where I made a mistake would be appreciated. Thanks.

69

Only earlier releases work, processing.org have decided not to support RaspberryPI at present, and never officially supported ARM64 arch or RaspberryPI4.

70

@monkstone I see. Got fooled by broken links above and instruction to download official builds instead. Where can I get @sampottinger 's latest aarch64 linux build? Many thanks. BTW what a pity new RPis are not supported, being a perfect system for inconspicuous art installations!

71

Agree, that is why i am still using RPI 3 with an older processing installation. Would love to go to RPI 4. I have been playing around with processing 4 on RPI 4 but couldn’t get the frame rate high enough on P2D mode that my animations are using

72

So RPI4 is a no-go, then. I wanted to use a camera and OpenCV and would want solid frame rates. Are you happy with your RPI3 and Processing 3 @hooeef ? Anything you can’t do? Might need to downgrade as I really really like the small factor. Thanks.

73

I don’t know, I think he’s removed the links however his github repro is here GitHub - sampottinger/processing: Source code for the Processing Core and Development Environment (PDE).

74

Not really happy @figle . I am really reaching the end of it to get consistent 30fps with a procedural and interactive drawing. Nothing fancy like image processing. I’d think you’d struggle with OpenCV. I truly wish to make it work on RPI 4 one day and have a more future proof path. Have considered going Nvidia Jetson but haven’t done so yet because I am afraid to run into the same issue I had with processing 4 on RPI 4 and having to deal with a less optimized code to handle P2D.

75

Well, it looks Processing for macOS will have to eventually (soon) embrace ARM architecture, so maybe it will be easier to support PIs then? Or does it not work that way?

https://www.jeffgeerling.com/blog/2020/what-does-apple-silicon-mean-raspberry-pi-and-arm64

76

From the Processing4 Readme “Roadmap”:

  • The current release runs well on Apple Silicon using Rosetta. We are currently unable to move to a fully native version for Apple Silicon because of other libraries that we rely upon (JavaFX, JOGL, etc). Once those are ready, we’ll need to do additional work to add Apple Silicon as a target (the same way we support both 64-bit and 32-bit, or ARM instead of Intel.) If there are updates on this issue, you’ll find them here.

…and from the linked issue discussion back in 2020:

The major obstacles preventing us from doing an Apple Silicon release are primarily the other library/platform components we rely upon. In particular:

  • Java VM – The Zulu builds should work fine.
  • JOGL – Not clear if/when there will be an Apple Silicon version of JOGL. It also doesn’t make sense to ship a version with OpenGL ripped out: Rosetta emulation is working fine (well?) and what would be the point? Bad experience for users, and a support nightmare for me.
  • JavaFX – There are Early Access builds of version 17 that include aarch64 (64-bit ARM) for macOS, as well, but we shouldn’t ship EA builds in a final product.
  • JNA – It looks like support has been added, though there are some indications that it’s incomplete. Haven’t had a chance to test further.

Those are all the pieces that come to mind at the moment. Once those are set, it will be necessary to do some additional work to add another “architecture” for macOS. But the major hurdles for this work were done when Gottfried and I added Raspberry Pi support. It was/is a similar situation: Linux was primarily 32- or 64-bit Intel, then 32- and 64-bit ARM had to be added as well. (Though we’ll only be using 64-bit Intel and 64-bit ARM on macOS.) Apple Silicon Support · Issue #128 · benfry/processing4 · GitHub

As JOGL seems like the major roadblock, a related thread on JOGL on Apple Silicon: jogl - JOGL for Mac ARM Silicon

1 Like
77

I haven’t had access to try LWJGL on an Arm mac. Works great on a Pi4, so libp5x is an option with right profile set - see post at Libp5x examples - Processing, LWJGL, Gradle and Java 11+ modules - #3 by neilcsmith

1 Like