set looping to false before beginDraw/endDraw

Author: codeanticode

core/src/processing/core/PApplet.java

@@ -308,6 +308,14 @@ public class PApplet extends Object implements ActivityAPI, PConstants {
 
   protected boolean looping;
 
+  // This auxiliary variable is used to implement a little hack that fixes
+  // https://github.com/processing/processing-android/issues/147
+  // on older devices where the last frame cannot be maintained after ending
+  // the rendering in GL. The trick consists in running one more frame after the
+  // noLoop() call, which ensures that the FBO layer is properly initialized
+  // and drawn with the contents of the previous frame.
+  protected boolean requestedNoLoop = false;
+
   /** flag set to true when a redraw is asked for by the user */
   protected boolean redraw;
 
@@ -1779,22 +1787,27 @@ public void handleDraw() {
     }
 
     insideDraw = true;
-    g.beginDraw();
+
 //    if (recorder != null) {
 //      recorder.beginDraw();
 //    }
 
     if (requestedNoLoop) {
-      // noLoop() was called in the previous frame, with a GL renderer, but now
+      // noLoop() was called sometime in the previous frame with a GL renderer, but only now
       // we are sure that the frame is properly displayed.
       looping = false;
-      requestedNoLoop = false;
-      // We are done, we only need to finish the frame and exit.
+      // Perform a full frame draw, to ensure that the previous frame is properly displayed (see
+      // comment in the declaration of requestedNoLoop).
+      g.beginDraw();
       g.endDraw();
+      requestedNoLoop = false;
       insideDraw = false;
       return;
     }
 
+    g.beginDraw();
+
+
     long now = System.nanoTime();
 
     if (frameCount == 0) {
@@ -1878,14 +1891,6 @@ synchronized public void loop() {
   }
 
 
-  // This auxiliary variable is used to implement a little hack that fixes
-  // https://github.com/processing/processing-android/issues/147
-  // on older devices where the last frame cannot be maintained after ending
-  // the rendering in GL. The trick consists in running one more frame after the
-  // noLoop() call, which ensures that the FBO layer is properly initialized
-  // and drawn with the contents of the previous frame.
-  private boolean requestedNoLoop = false;
-
   synchronized public void noLoop() {
     if (looping) {
       if (g instanceof PGraphicsOpenGL) {

core/src/processing/core/PSurfaceNone.java

@@ -434,7 +434,10 @@ public boolean stopThread() {
     if (thread == null) {
       return false;
     }
+
     thread.interrupt();
+    thread = null;
+
     return true;
   }
 
@@ -452,9 +455,8 @@ public void setFrameRate(float fps) {
 
 
   protected void checkPause() throws InterruptedException {
-//    if (paused) {
-      synchronized (pauseObject) {
-        while (paused) {
+    synchronized (pauseObject) {
+      while (paused) {
         pauseObject.wait();
       }
     }

core/src/processing/opengl/PGraphicsOpenGL.java

@@ -5709,6 +5709,7 @@ protected void drawPixels(int[] pixBuffer, int x, int y, int w, int h) {
 
   @Override
   protected void saveState() {
+/*
     // Queue the pixel read operation so it is performed when the surface is ready
     pgl.queueEvent(new Runnable() {
       @Override
@@ -5727,21 +5728,31 @@ public void run() {
         } catch (ArrayIndexOutOfBoundsException e) {}
       }
     });
+    */
   }
 
 
   @Override
   protected void restoreState() {
   }
 
+
   @Override
   protected void restoreSurface() {
+    /*
     if (changed) {
       changed = false;
       if (restorePixels != null) {
         // Set restore count to 2 so it draws the bitmap two frames after surface change, otherwise
         // the restoration does not work because the OpenGL renderer sometimes resizes the surface
-        // twice after restoring the app to the foreground (?)
+        // twice after restoring the app to the foreground... this may be due to broken graphics
+        // drivers, hacks in the GLSurfaceView class from the Replica Island game point to that,
+        // although those seem to be quite old:
+        // https://gamedev.stackexchange.com/questions/12629/workaround-to-losing-the-opengl-context-when-android-pauses
+        // "It fails in a very specific case: when the EGL context is lost due to resource constraints,
+        //  and then recreated, if GL commands are sent within two frames of the surface being created
+        //	then eglSwapBuffers() will hang."
+        // However, the same number showing up makes me thing this issue continue to exist to this day.
         restoreCount = 2;
       }
     } else if (restoreCount > 0) {
@@ -5752,6 +5763,7 @@ protected void restoreSurface() {
         restorePixels = null;
       }
     }
+    */
   }
 
   //////////////////////////////////////////////////////////////