Loading...
Logo
Processing Forum
Core Library Questions
noncom
noncom

Another memory leak in PImage?

in Core Library Questions  •  1 year ago  
Hello! I have created an application that loads a set of photos and spreads them by separate windows. Each window has 2 rows and 8 columns of photos. By pressing the "right" and "left" buttons, the "window ribbon" may be scrolled left and right. This is done by first preparing two images by drawing them on PGraphics canvas and copying to separate PImages. Then the same PGraphics canvas is used to draw these images progressing their position so as for the "scrolling" effect to occure. All PImage instances are pre-created, and the copy() method is used to cache the right and left window (there images are too drawn with the copy() method to the canvas) because I know that the renderer caches the images and there is a bug in OPENGL renderer that stores them indefinetely. That first bug took me a weak of sweating while trying to find an error in my code. Finally, I was surprised by finding that topic in the internet that says that it is a bug in OPENGL and that OPENGL2 or present P3D would do fine. I have first reimplemented the render through P3D, it was lagging waaaaay toooo muuuuuch! Then I have downloaded Processing 2.04a and used OPENGL2 (which is named just OPENGL there). Same memory leak! It is not huge, but it builds up and lets only about 50 scrollings to be done.

Could anyone comment on that?

Aside from that, I am interested, how would you implement scrolling? I use the pre-draw method because aside from the images, there are also many other things drawn and the effect that I acheive is that they are not drawn while go partially out of the canvas, the PGraphics cuts it out.

EDIT: Please note that all the other things drawn aside from images are not the cause. Since commenting out the single line responsible for drawing the images, eliminates the used heap growth. I use visualjvm to monitor the condition.

Replies(3)

David Wilson
David Wil..

Re: Another memory leak in PImage?

1 year ago
Post some code that demonstrates the issue?

D.
noncom
noncom

Re: Another memory leak in PImage?

1 year ago
Ok, the code of the project is too huge to post here, I will try to cut out the related parts of the GUIWindowRibbon class that implements all this.

this is in the GUIWindowsRibbon class variables definition:
Copy code
  1. public GUICanvasGL canvas;
  2. PImage winAnimFrom;
  3. PImage winAnimTo;
  4. PImage animationImg;
the entire code of the GUICanvasGL class is small enough to fit in the post:

Copy code
  1. public class GUICanvasGL extends GUIImage{
  2. //GLGraphicsOffScreen canvas; // NO WORK WITH OPENGL2 SADLY
  3. PGraphics canvas;
  5. public GUICanvasGL(GUIElement parent, float x, float y, float xx, float yy) {
  6. super(parent, x, y, xx, yy);
  7. setGraphics(xx, yy);
  8. }

  10. public void setGraphics(float xx, float yy) {
  11. //canvas = new GLGraphicsOffScreen(Global.applet, (int)xx, (int)yy, false);
  12. canvas = Global.applet.createGraphics((int)xx, (int)yy, PApplet.OPENGL);
  13. }
  15. public PGraphics getCanvas() {
  16. return canvas;
  17. }
  19. public void flip() {
  20. this.setContent(canvas.get());
  21. }
  22. }
Then, continuing the GUIWindowsRibbon class, there is the related part of it's constructor:
Copy code
  1. this.canvas = new GUICanvasGL(this, 0, 0, this.bounds.size.x, Service.height);
  2. winAnimFrom = Global.applet.createImage((int)this.bounds.size.x, (int)this.bounds.size.y, PApplet.RGB);
  3. winAnimTo = Global.applet.createImage((int)this.bounds.size.x, (int)this.bounds.size.y, PApplet.RGB);
Then the GUIWindowsRibbon class method that is triggered upon scroll button press. It prepares the scrolling surface:
Copy code
  1. void startAnimaton(int direction, int indexA, int indexB) {
  2. PGraphics context = canvas.getCanvas();
  3. int sizeX = (int) bounds.size.x;
  4. int sizeY = (int) bounds.size.y;

  6. //////////////////////////////////////////////////////////first window (from)
  7. context.beginDraw();
  8. GUIWindow windowA = getWindow(indexA);
  9. windowA.alsoDrawFor(context, (int) - windowA.getAbsoluteBounds().start.x, (int) -windowA.getAbsoluteBounds().start.y);
  10. context.endDraw();
  11. winAnimFrom.copy(context, 0, 0, context.width, context.height, 0, 0, context.width, context.height);

  13. //////////////////////////////////////////////////////////second window (to)
  14. context.beginDraw();
  15. GUIWindow windowB = getWindow(indexB);
  16. windowB.alsoDrawFor(context, (int) - windowB.getAbsoluteBounds().start.x, (int) -windowB.getAbsoluteBounds().start.y);
  17. context.endDraw();
  18. winAnimTo.copy(context, 0, 0, context.width, context.height, 0, 0, context.width, context.height);

  20. animTimer = Global.timerServer.createTimerGlobal(intervalSlide);
  21. animDirection = direction;
  22. isAnimating = true;

  24. animationImg = Global.applet.createImage(context.width, context.height, PApplet.RGB);
  25. }
Comment: the   windowA.alsoDrawFor and  windowB.alsoDrawFor  methods only draw things like line() and rect(), and an image - for image elements. Needless to say, all images are cached in memory once and are never loaded twice from the hard drive. I have also reimplemented the image drawing statements through copy() to avoid asking the renderer about that, instead doing the pixeldata copying directly.

Then, the related part from the GUIWindowRibbon update method:
Copy code
  1. if(isAnimating) {
  2. float percent = animTimer.getPercent();
  4. if(percent > 1f) percent = 1f;
  6. PGraphics context = canvas.getCanvas();
  7. context.beginDraw();
  8. context.background(0);//.clear(0);
  9. float size = bounds.size.x;
  10. float start = 0;
  11. switch(animDirection) {
  12. case PApplet.LEFT: // <<-- [2][1]
  13. start = - (float)size * percent;
  14. context.image(Global.imageDB.getGUIPart(Image.BG), start, 0);
  15. context.image(Global.imageDB.getGUIPart(Image.BG), size + start, 0);
  16. context.image(winAnimFrom, start, 0);
  17. context.image(winAnimTo, size + start, 0);
  18. break;
  19. case PApplet.RIGHT: // -->> [1][2]
  20. start = (float)size * percent;
  21. context.image(Global.imageDB.getGUIPart(Image.BG), start, 0);
  22. context.image(Global.imageDB.getGUIPart(Image.BG), - size + start, 0);
  23. context.image(winAnimFrom, start, 0);
  24. context.image(winAnimTo, - size + start, 0);
  25. break;
  26. }
  27. context.endDraw();
  28. animationImg.copy(context, 0, 0, context.width, context.height, 0, 0, animationImg.width, animationImg.height);
  29. this.hideChildren();
  30. if(percent >= 1) {
  31. isAnimating = false;
  32. animationImg = null;
  33. winAnimFrom.removeCache(canvas.getCanvas());
  34. winAnimTo.removeCache(canvas.getCanvas());
  35. System.gc();
  36. this.showChildren();
  37. if(!this.showWindowTitles) hideTitlesOfAllWindows();
  38. return;
  39. }
  40. }
And finally, the GUIWindowRibbon class draw method:
Copy code
  1. @Override
  2. void customDraw() {
  3. if(isAnimating){ //animationImg != null) {
  4. Global.applet.image(animationImg, absoluteBounds.start.x, absoluteBounds.start.y);
  5. }
  6. }
I have to say that I have tried all kinds of copy() methods and getTexture() methods and such... only this method allows to see the image (otherwise it is black).
amnon.owed
amnon.owed

Re: Another memory leak in PImage?

1 year ago
As someone who has battled with Processing's opengl memory leak issues, I can sympathise.

However if you want to have issues fixed towards 2.0 for yourself and all of us, you should:

1. Create a small runnable (!) code example displaying the issue.
2. Search the bug tracker and if it's not already there, add the issue to the bug tracker.
3. Preferably include a zipped version of the code example displaying the issue in your bug report.

Top Reply

Statistics

  • 3 Replies
  • 1351  Views
  • 0 Followers

Actions

Related Posts