G4P library crashes with multi-window

hello #Quark

I have noticed several time instability problems when using the G4P library to generate multiwindows. I’m using G4P builder tool in Processing 3.7. I stripped the code to the bare minimum to narrow down what could generate the error. The code (see below) loads a .obj file, set a .JPG picture as background to main window and rotate the .obj in the main window. It also create an empty window using G4P with P3D randerer.

If the createGUI() line is commented the code runs for hours with no problem. If I uncomment the createGUI() line, the code crash with the error reported below. The behaviour is different depending upon the platform used:

  • Windows 10 / core i5 / NVIdia GEForce 920MX ==> code fails after few minutes
  • Windows 10 / core i5 / Intel 710 ==> code fails after few 10 of second
  • old MAC with OsX mounain lion + NVIDIA ==> code is really slow but never fails.

Same behavior if I export the code as .exe. I’m running on both PC Java8.

I really need to get this stable (not many time left to the end of my project…)… Are you aware about that kind of trouble on Windows10 ? any hint to get it stable ?

Appreciate very much your help,

///////////////////// code////////////////////////////////////////////////////////////


 import g4p_controls.*;
    
    PShape Arr,Tip, Gr, Rd, Pt;
    PShape s;
    float Rx, Ry=80, Rz ,mix=0.0001;
    PImage bg;
    
    public void setup(){
      bg = loadImage("Back.JPG");
      bg.resize(500,650);
      size(500, 650, P3D);
      background(bg);
      s = loadShape("wingXstrmUs.obj");
      createGUI();                                                            //<<====== this is the problematic line
    }
    
    public void draw() {
      background(bg);
      // generate random angles
      Rx=(1-mix)*Rx+mix*radians(random(180));
      Ry=(1-mix)*Ry+mix*radians(random(180));
      Rz=(1-mix)*Rx+mix*radians(random(180));
      
      // draw the object rotation in the main window
      translate(width/2, height/2);
      rotateX (Rx);
      rotateY(Ry);
      rotateZ(Rz);
      scale(4, 4, 4);
      shape(s, 0, 0);
    }
    ////// Below code generated by G4P builder in the GUI tab to generate the empty window
    
    synchronized public void win_draw1(PApplet appc, GWinData data) { //_CODE_:window1:517716:
    appc.background(230);
    } //_CODE_:window1:517716:
    
    // Create all the GUI controls. 
    // autogenerated do not edit
    
    public void createGUI(){
      G4P.messagesEnabled(false);
      G4P.setGlobalColorScheme(GCScheme.BLUE_SCHEME);
      G4P.setCursor(ARROW);
      surface.setTitle("Sketch Window");
      window1 = GWindow.getWindow(this, "Window title", 0, 0, 500, 650, P3D);
      window1.noLoop();
      window1.addDrawHandler(this, "win_draw1");
      window1.loop();
    }
    
    // Variable declarations 
    // autogenerated do not edit
    GWindow window1;

////////////////////////////// Error generated by Processing

JRE version: Java™ SE Runtime Environment (8.0_162-b12) (build 1.8.0_162-b12)

Java VM: Java HotSpot™ 64-Bit Server VM (25.162-b12 mixed mode windows-amd64 compressed oops)

Problematic frame:

C [msvcrt.dll+0x7436f]

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

Could not run the sketch (Target VM failed to initialize). For more information, read revisions.txt and Help ? Troubleshooting

You mean Processing v3.3.7, right? Just to clarify.

To clarify, does your sketch runs but it fails? Or your sketch takes about 10 seconds to try to load and then it fails?

Do you need both windows to run with the P3D renderer? I have read couple of posts before that when using Processing java with multiple sketch Windows, only one sketch is allowed to run in P3D mode. One test is to make only of of your windows P3D to see if it eliminates the problem. Even if this solution is not suitable for you, it will be a good clue and one step in the right direction.

Kf

1 Like

Not much use if you don’t provide the resources needed by the code i.e. Back.JPG and wingXstrmUs.obj

BTW use @ before the members ID if you want them to get a message, # won’t hack it. :wink:

1 Like

Forgot to mention the size() method should be the first line inside setup() so change it to

public void setup(){
      size(500, 650, P3D);
      bg = loadImage("Back.JPG");
      bg.resize(500,650);
      background(bg);
      s = loadShape("wingXstrmUs.obj");
      createGUI();                                                            //<<====== this is the problematic line
    }
1 Like

Dear Kfrajer,

Thanks for the hint, I will try to set only 1 P3D randerer and let you know the outcome.
To clarify the actual situation, the sketch loads, run for sometime and then crash.

Rgds

Dear @quark @kfrajer

I did the test with P3D on the main and P2D on the subwindow ==> I do get the same crash as earlier.
I set the size at first line in the setup ==> I do get the same crash as earlier.

I attached the wingXstrmUs.obj and the Back.JPG to this message such that you can test - they are just a pictures and a 3D object… nothing fancy there…

I must admit I’m a bit puzzled, any help welcomed…!

Back|500x500

OOps the .obj and the .JPG did not made it throught this chat.
How can I share those files with you ?

Modify your sketch code to remove the need for resources i.e. the image and object file.

Does the modified sketch still crash in Windows 10? If so paste the sketch code here together with the error message.

1 Like

hm hm hm… interesting,
The code has been stripped to the bone… there is nothing left in any of the windows… just displaying background with fixed colors and … still crashing after ~20s (conf Windows10 + INTEL 620 HD Graphics) !!!
The code is below + the error in the next message.

/////// Code ///

import g4p_controls.*;

public void setup(){
size(500, 650, P3D);
background(10);
createGUI(); //<<====== this is the problematic line
}

public void draw() {
background(10);
}

synchronized public void win_draw1(PApplet appc, GWinData data) { //CODE:window1:420602:
background(10);
} //CODE:window1:420602:

// Create all the GUI controls.
// autogenerated do not edit
public void createGUI(){
G4P.messagesEnabled(false);
G4P.setGlobalColorScheme(GCScheme.BLUE_SCHEME);
G4P.setCursor(ARROW);
surface.setTitle(“Sketch Window”);
window1 = GWindow.getWindow(this, “Window title”, 30, 30, 600, 800, P3D);
window1.noLoop();
window1.addDrawHandler(this, “win_draw1”);
window1.loop();
}

// Variable declarations
// autogenerated do not edit
GWindow window1;

I was able to duplicate the problem under Windows 10, it occured within seconds. What is interesting is that it also happened on my iMac using the latest version of OSX, but in this case it took about 20 minutes to crash.

I believe I have identified the cause and have a simple solution. I have the sketch running under Windows 10 on my laptop as I type. It has been going for about 15 minutes. :joy:

I will leave it for another 15 minutes to be sure but in the meantime please can you delete all the debug data in your last two posts otherwise people might not scroll down to my answer.

1 Like

Might be a bit premature here. Hang on while I do some more testing.

1 Like

Delete done !! I cross fingers…

There appears to be 2 issues here

  1. In Windows 10 it doesn’t like two OpenGL windows (P2D or P3D)
  2. In the draw method for a GWindow, all calls to Processing methods must be prefixed with the PApplet parameter (see code below)

Try this in Windows, it was more stable on my system but not perfect. I have tried ‘2 P3D’ windows on my iMac which each window having its own spinning cube and it seems stable.

import g4p_controls.*;

public void setup() {
  size(500, 650, P3D);
  background(10);
  createGUI();
}

public void draw() {
  background(255, 200, 200);
  translate(width/2, height/2);
  rotateX(frameCount / 97.8);
  rotateY(frameCount / 20.0);
  rotateZ(frameCount / 31.1);
  fill(20, 255, 20);
  box(150);
}

synchronized public void win_draw1(PApplet appc, GWinData data) { //CODE:window1:420602:
  appc.background(200, 200, 255);
} //CODE:window1:420602:

// Create all the GUI controls.
// autogenerated do not edit
public void createGUI() {
  G4P.messagesEnabled(false);
  G4P.setGlobalColorScheme(GCScheme.BLUE_SCHEME);
  G4P.setCursor(ARROW);
  surface.setTitle("Sketch Window");
  window1 = GWindow.getWindow(this, "Window title", 30, 30, 600, 800, JAVA2D);
  window1.noLoop();
  window1.addDrawHandler(this, "win_draw1");
  window1.loop();
}

// Variable declarations
// autogenerated do not edit
GWindow window1;
2 Likes

I have tried the above code on windows10 and indeed it keeps crashing after few second whatever mix of P2D or P3D. Seems stable with JAVA2D as far as I can see. Is there any hope to get that fixed ?

I was not aware about prefixing all Processing methods - thanks for the hint. Could it be also an explanation for the instability ?

Thks

I don’t think there are any changes I could make to G4P that would solve the problem. Early versions of Processing didn’t use OpenGL for P2D and P3D there was never a problem with G4P and multiple windows.

When they started using OpenGL there appeared to be an issue with creating multiple OpenGL surfaces in general. I had to completely re-write the G4P code that handled multiple windows because the event model for OpenGL is very different from the standard Java one.

Must remember that Processing was never designed to be multi-window and (in this area) G4P pushes Processing beyond its comfort zone.

The short answer is yes. Each window is effectively a separate sketch with it own event thread and drawing surface so

synchronized public void win_draw1(PApplet appc, GWinData data) {
  background(200, 200, 255);
}

will attempt to set the background colour of the main window rather than the GWindow. At the very least it can cause flickering in the main window at worse it could crash the program depending on what the Processing method does.

3 Likes

Ok thanks for the explanation. Still I do understand that this is specific to OpenGl, meaning using g4p on multiwindows with Java2D and only ONE occurence of PxD is reasonably safe ?

Or would you advice to forget multiwindows and group all in the main ? I m heading for an app runing smooth on many platforms. As I m using unfolding Map library I have no other choices than runing P2D…

Thks on avance for advice…

Envoyé depuis Yahoo Mail pour Android

I have not used unfolding Map library but if it behaves properly (according to Processing guidelines), then G4P should work with it in the same P2D window. Just try them out.

Experimentation is the name of the game. A lot of people get an idea for a sketch, find some library/libraries and then start building the application, they get so far and then are scared to try things out in case it breaks what they have done so far. So create some small trial sketches to try out different options get a feel of whats possible before you work on the real thing.

Some G4P features that might help

  • G4P provides the floating pane which can hold other G4P controls, the pane cane be expanded /collapsed.
  • G4P also has the GGroup class which allows a collection of controls to be ‘grouped’ so that single commands make them visible/invisible or even fade in/out.
2 Likes

Pan and group sound good. I will let ok attends example ans teybthem out. Thanks for the hint !

Hi @quark

Thanks for your investigation, as I’m now encountering the exact same issue (six years later!).

Do you happen to have any further insights? Or maybe found a workaround?

Do you think, as a last resort, it would be feasible to start the second sketch in a completely new JVM and then somehow use maybe network to get the data from one sketch to another?

There have been 16 versions of G4P, 4 versions of GUI Builder and Processing has gone from 3.3.7 to 4.3 in the last 6 years so any conclusions reached in this thread are irrelevant.

If you can provide a simple sketch using the latest versions of G4P, GUI Builder and Processing that demonstrates the problem you are experiencing then I will investigate further. :grin:

1 Like