Issue with G4P and P2D renderer on raspberry Pi

jb4x · August 11, 2018, 9:17pm

Hello everyone,

I need to be able to use some sliders and buttons in a sketch that run on a raspberry PI 3 (with raspbian) and thought about using G4P but I ran into a problem.

This is the test code I am using:

import g4p_controls.*;

GButton myBtn;

void setup() {
  size(500, 500, P2D);
  myBtn = new GButton(this, 10, 10, 100, 20, "TEST");
}

void draw() {
  background(20);
}

void handleButtonEvents(GButton button, GEvent event) {
  println("Button clicked");
}

When I try to run it, the following sentence appears in red in the console:
setMatrix is not vailable with this renderer

The program launch anyway and after a while the button appears but then I can’t do anything inside the window. Also, if I wait for long enough, another message appears that I can’t decrypt. I also don’t know where to find the revisions.txt file stated at the end.

RunnableTask.run(): A caught exception occured on thread main-Display-.x11_:0.0-2-EDT-1: RunnableTask[enqueued true[executed false, flushed false], tTotal 0 ms, tExec 0 ms, tQueue 0 ms, attachment null, throwable java.lang.RuntimeException: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>]
java.lang.RuntimeException: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>
	at jogamp.newt.DefaultEDTUtil.invokeImpl(DefaultEDTUtil.java:252)
	at jogamp.newt.DefaultEDTUtil.invoke(DefaultEDTUtil.java:165)
	at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:442)
	at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2782)
	at jogamp.newt.WindowImpl.setPosition(WindowImpl.java:2911)
	at jogamp.newt.driver.x11.X11UnderlayTracker.windowMoved(X11UnderlayTracker.java:152)
	at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4386)
	at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:4317)
	at jogamp.newt.WindowImpl.positionChanged(WindowImpl.java:4558)
	at jogamp.newt.WindowImpl.sizePosMaxInsetsVisibleChanged(WindowImpl.java:4865)
	at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method)
	at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:112)
	at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4449)
	at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4443)
	at jogamp.newt.WindowImpl.createNative(WindowImpl.java:777)
	at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1248)
	at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1318)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:127)
	at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:375)
Caused by: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>
	at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
	at jogamp.newt.WindowImpl$SetPositionAction.run(WindowImpl.java:2884)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:145)
	... 1 more
DefaultEDT.run(): Caught exception occured on thread main-Display-.x11_:0.0-2-EDT-1: RunnableTask[enqueued false[executed true, flushed false], tTotal 10983 ms, tExec 10983 ms, tQueue 0 ms, attachment null, throwable java.lang.RuntimeException: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>]
java.lang.RuntimeException: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>
	at jogamp.newt.DefaultEDTUtil.invokeImpl(DefaultEDTUtil.java:252)
	at jogamp.newt.DefaultEDTUtil.invoke(DefaultEDTUtil.java:165)
	at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:442)
	at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2782)
	at jogamp.newt.WindowImpl.setPosition(WindowImpl.java:2911)
	at jogamp.newt.driver.x11.X11UnderlayTracker.windowMoved(X11UnderlayTracker.java:152)
	at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4386)
	at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:4317)
	at jogamp.newt.WindowImpl.positionChanged(WindowImpl.java:4558)
	at jogamp.newt.WindowImpl.sizePosMaxInsetsVisibleChanged(WindowImpl.java:4865)
	at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method)
	at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:112)
	at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4449)
	at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4443)
	at jogamp.newt.WindowImpl.createNative(WindowImpl.java:777)
	at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1248)
	at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1318)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:127)
	at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:375)
Caused by: java.lang.RuntimeException: Waited 5000ms for: <2dc15, 1eca7c5>[count 1, qsz 0, owner <main-FPSAWTAnimator#00-Timer0>] - <main-Display-.bcm.vc.iv_nil-1-EDT-1>
	at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
	at jogamp.newt.WindowImpl$SetPositionAction.run(WindowImpl.java:2884)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:145)
Could not run the sketch (Target VM failed to initialize).
For more information, read revisions.txt and Help â†’ Troubleshooting.

I did some more tests and here what I found out:

Without the P2D renderer it works just fine with no surprise (on my computer-W10 and on my raspberry Pi).
Now, weirdly enough, I also get this error on my computer and the sketch takes way more time to load but I can use the program correctly afterwards which make sense with what I’ve read on the internet saying that it is more of a warning than an actual error.
The long error message does not appear on my computer either.

Can you please help me figure out a way to make it work or guide me to another library. I tried several other one but I really like how easy it is with this one to control the action on the events.

PS : I was using ControlP5 at first but it run really slow on my Pi, and not on my computer…

jb4x · August 12, 2018, 12:25pm

I did some more digging and there is a subject that come back often: JOGL and the problem could (maybe?) come from there. Except that it starts to be a bit too advance for me so I don’t get 75% of what I read…

From what I somehow got, it has to do with how the raspberry pi is handling hardware-supported 3D graphics (using NEWT) and how computer does (with AWT). And processing is using JOGL because it can support both toolkit (if I can call it like this?)

Please correct me if I say any nonsense

Now can it really be connected to my problem and is there something I can do about it?

Another lead I got was by looking at the source code of the library.
I noticed the use of PGraphicsJava2D variables. If i’m using the P2D renderer shouldn’t it be PGraphicsOpenGL variables and could it be the problem?

Now, if it is, why would it work on my computer and not on my raspberry?

Finally concerning other libraries that’s what I got from my research:

G4P: not working on the raspberry PI but easy to use and to deal with events
ControlP5 : it was my first choice and works fine on my computer but when I launch the code on the raspberry, the application is super slow
Interfascia: does not implement sliders

Any other library ideas?

Thanks again

quark · August 12, 2018, 4:25pm

This is a warning generated by Processing when using G4P with the P2D renderer. It will not affect how your program works and can be ignored.

The stacktrace you also posted appears to be related to using OpenGL. Make sure you are using the latest drivers. In Processing P2D and P3D use OpenGL (& NEWT) but the default renderer uses Java AWT to create the sketch window and handle events.

jb4x · August 12, 2018, 7:21pm

Thank you @quark for your time. What you posted give me a test idea.

I went to the setting of my raspberry to try to change the GL drivers. Result:

GL (Full KMS): I got a bunch of errors in the console but it is working fine
GL (Fake KMS): the same as with Full KMS
Legacy: This is where I get the problem

Sadly, changing to GL (Full or Fake KMS) is not a solution to me since the GL Video library works only with the Legacy driver (and I don’t know another way to access the data from the camera with the PI).

Is there a way then to overcome that problem?

gohai · August 13, 2018, 4:52am

@jb4x If the P2D renderer works for you without G4P, then I would suspect that some aspect of how this library works is throwing a wrench into it working on the Pi with the “legacy” graphics driver. It could, for example, be that the library is expecting to be able to drawing operations outside of draw (I don’t know how G4P works, but it sure does something behind the back of the sketch…).

The RuntimeException: Waited 5000ms is always a sign that something between JOGL and the graphics driver is amiss.

I don’t think this will fixed anytime soon. When Raspbian adds support for the camera and video decode with the “GL” video drivers, the “GLVideo” library will get updated so that it works with those. But I don’t know when this will happen.

jb4x · August 13, 2018, 5:54am

Thanks @gohai.

I’m now thinking about using a usb camera (I’m currently using a camera plugged on the CSI port) to do the job in order to be able to use the Video library and thus be able to run the sketch with the JAVA2D renderer and make G4P works.

Would the Video library works using an usb cable camera?
What would be the inconvenient/advantages of using a USB camera compare to the CSI plugged one?

quark · August 13, 2018, 6:42am

Since G4P works with both P2D and P3D on Windows, OSX and Linux without problems then I suggest it a Processing <> ‘legacy’ OpenGL problem (possibly) being exposed by G4P.

Processing has a documented callback feature for libraries to seamlessly hook into the main thread method which is then executed after the sketch (users) draw() method but before the frame is finally rendered and shown and G4P uses this. The only G4P feature that might cause problems is if you create secondary windows using the GWindow class since Processing was not designed to support multiple windows, but I am assuming you are not using this feature.

jb4x · August 13, 2018, 6:44am

No I am not.
I’m just using G4P to draw a slider and some buttons. That’s all.

quark · August 13, 2018, 7:08am

In which case G4P is only using documented features of Processing, it must be an issue with Processing <> OpenGL.

gohai · August 14, 2018, 3:55am

@quark This page lists the following about Processing’s post callback:

Method called after draw has completed and the frame is done. No drawing allowed.

So I am just wondering whether it would make sense to try to do all of G4P’s drawing in pre or draw instead?

quark · August 14, 2018, 8:07am

You misunderstood my answer. G4P already uses the draw callback to perform ALL graphics operations such displaying controls. Sliders use the pre callback to determine (not draw) the thumb position (easing). The post callback is used to remove deleted controls to avoid concurrent access violations caused if attempted during the draw phase.

neilcsmith · August 14, 2018, 9:33am

@gohai isn’t the most common cause of this because people are doing too much in setup()? Often see it when people are loading files that are too big. Does the Java2D renderer normally work on Pi with the GL renderer? Wondering aloud whether initializing the Java2D offscreen graphics is taking too long, or triggering a deadlock?

Make sure to use the beta version with GStreamer 1.x. The bindings work on the Pi, so assume the Video library will. Performance may be an issue (can’t even hack it to use my faster workaround without full GL support).

jb4x · August 14, 2018, 9:51am

Thank you @neilcsmith, I will try it out then.
Sadly I can’t right now but I will definitly let you know as soon as I got the result.

quark · November 24, 2018, 4:43pm

I suggest you read this discussion as it might help resolve your issue.

Topic		Replies	Views
Getting java exception in G4P while creating child window Libraries	6	490	May 17, 2020
G4P with P2D/P3D :: Processing bug Libraries	0	1810	November 24, 2018
G4P NullPointerexception (Unknown Source) Electronics (Arduino, etc.)	3	412	June 30, 2021
G4P GUI button function Libraries	2	1485	August 9, 2019
G4P controls not working in diferrent windows Libraries	0	228	March 12, 2022

Issue with G4P and P2D renderer on raspberry Pi

Related topics