"filter(BLUR)" causes program to crash after many frames.

edited February 2017 in Questions about Code

I use filter(BLUR) in a large project and it never caused problems on Windows. When I run the same program on Linux it causes the program to crash after many frames have passed.

Here's a simple program that crashes after about 300-400 frames

PGraphics pg;

void setup() {
    size(500, 500, P2D);


void draw() {

    text(frameCount, width/2, height/2);

    int newWidth = int(random(400, 500);
    int newHeight = int(random(400, 500);
    pg = createGraphics(newWidth, newHeight, P2D);
    pg.ellipse(pg.width/2, pg.height/2, 60, 60);
    pg.filter(BLUR, 2);

I deliberately create PGraphics in each frame (and don't actually draw it, but that's not relevant) because that's similar to what I do in my project.

Here's the error message, apparently the heap gets full or something, but it makes no sense to me.

java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
    at com.jogamp.common.util.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
    at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103)
    at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:206)
    at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
    at javax.media.opengl.Threading.invoke(Threading.java:191)
    at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:541)
    at processing.opengl.PJOGL.requestDraw(PJOGL.java:688)
    at processing.opengl.PGraphicsOpenGL.requestDraw(PGraphicsOpenGL.java:1651)
    at processing.core.PApplet.run(PApplet.java:2256)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at processing.core.PImage.blurARGB(PImage.java:1432)
    at processing.core.PImage.filter(PImage.java:1182)
    at processing.opengl.PGraphicsOpenGL.filter(PGraphicsOpenGL.java:5816)
    at blurheap.draw(blurheap.java:39)
    at processing.core.PApplet.handleDraw(PApplet.java:2386)
    at processing.opengl.PJOGL$PGLListener.display(PJOGL.java:862)
    at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:665)
    at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:649)
    at javax.media.opengl.awt.GLCanvas$10.run(GLCanvas.java:1289)
    at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1119)
    at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:994)
    at javax.media.opengl.awt.GLCanvas$11.run(GLCanvas.java:1300)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$200(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

Any thoughts?


  • try moving line 16 into setup maybe.

    a new pgraphics every 60th of a second seems a bit brutal. and it looks like it's eating memory.

  • edited February 2017

    Can't do that because I need all those PGraphicsto be of different size so createGraphics(newWidth, newHeight, P2D); is necessary unfortunately (I didn't make that clear in my initial post, sorry).

    Is there a way I could reset everything in the PGraphicsobject without actually making a new object?

  • You can create one in setup large enough and then work in a smaller area. If you display the object in draw, you could do it using image(pg,cornerX,cornerY,pg_width,pg_height); This is a temporal solution. Maybe you should report this as a bug to the Processing Foundation.


  • Yes, that workaround came to my mind, but it will require a lot of code rewriting which I wanted to avoid. Thanks anyway!

Sign In or Register to comment.