Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dispose handlers not called when stop button pressed #631

Open
processing-bot opened this issue May 8, 2016 · 6 comments
Open

dispose handlers not called when stop button pressed #631

processing-bot opened this issue May 8, 2016 · 6 comments
Labels

Comments

@processing-bot
Copy link
Collaborator

Created by: jdf

In the following sketch, the dispose handler is called when the escape key is pressed, but not when the stop button is pressed.

dispose_bug

SampleLibrary s;
void setup() {
  size(200, 200, P3D);
  s = new SampleLibrary(this);
}

void draw() {
  background(255);
  fill(0);
  text("" + millis(), 20, 20);
}

SampleLibrary.java

import processing.core.*;

public class SampleLibrary {

  public SampleLibrary(PApplet parent) {
    parent.registerMethod("dispose", this);
  }

  public void dispose() {
    System.err.println("disposed!");
  }
}
@processing-bot
Copy link
Collaborator Author

In GitLab by @hamoid on May 9, 2016, 11:07

Related dispose() issue: processing/processing#4381

@processing-bot
Copy link
Collaborator Author

In GitLab by @hamoid on May 26, 2016, 11:34

I just wanted to point out why this might be important. With a library I wrote (the Video Export Library), there's issues like this:

I'm on windows 8.1 with Processing 3.1 It seems the only thing that works for me is using the Stop button in processing. using exit(), closing the app by pressing the red x in the upper corner of the window, or pressing esc results in a broken movie file...

The strangest this is that if i use P2D and begin and end a recording and then close the window by clicking on the red x in the upper corner produces a working video...using esc or exit() still do not work...

The reason is that the library can not properly shut down when closing the sketch because dispose() is not called in many cases. I'll look at the related source when I get a moment, but I can imagine this is not a trivial thing to fix (I hope I'm wrong :).

@processing-bot
Copy link
Collaborator Author

Created by: codeanticode

This happens with all other renderers, not only OpenGL. If you follow the stop handler in the Java editor, you will reach the following line in Runner.close():

// TODO make sure stop() has already been called to exit the sketch

which makes me think that something is missing to properly dispose the running sketch when stopping it from the editor. I guess that once vm.exit(0) is called, there is nothing you can do inside the sketch to catch the VM exit event (sigkill signal?). @benfry should be able to answer this question better.

@processing-bot
Copy link
Collaborator Author

Created by: haschdl

like @jdf I have a custom library that is being affected by this issue. I have an open issue that Processing is freezing, because the it is not possible to capture that the sketch is being terminated when user presses Stop button in the PDE.

@jdf I took a look at your source code for dispose() and it seems you have not found a workaround? https://github.com/leadedge/SpoutProcessing/blob/453e0d861359556dec82f22d2bc35f994f8c81cb/src/spout/Spout.java#L184-L197

@benfry this is quite old, but still affecting Processing 4.1. What would be the advice, should a new issue be created in processing4 repo?

@processing-bot
Copy link
Collaborator Author

Created by: benfry

I'll move it to the 4.x repo…

@processing-bot
Copy link
Collaborator Author

Created by: haschdl

Looking forward to receiving updates on this. I will update my own library to make sure resources get disposed on ESC and closing the window, and leave a reminder that STOP button should be avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant