Titanium

[TIMOB-1613] iOS: ImageView not releasing memory when image reassigned

GitHub Issuen/a
TypeBug
PriorityLow
StatusClosed
ResolutionWon't Fix
Resolution Date2017-08-08T18:47:46.000+0000
Affected Version/sRelease 3.0.0
Fix Version/sn/a
ComponentsiOS
Labelscore
Reporterdhpublic (at gmail)
AssigneeIngo Muschenetz
Created2011-04-15T02:57:20.000+0000
Updated2017-08-08T18:47:46.000+0000

Description

I think my problem only occurs when ran from inside a setInterval. If I simply load 150 images sequentially into an imageview's image, then only 15 MB of real memory is used. However, when performed inside the setInterval's callback, the real memory usage escalates to nearly 60 MB if 100 images are used, and up to about 100 MB if 150 images are used. It will stay at that level throughout subsequent loops until the app is shut down. I obtained these numbers by running Instruments with Activity Monitor.

I have attached a sample project with the relevant 10-12 lines of code in the app.js file and 100 images of 20 KB each.

Attachments

FileDateSize
testimageview.zip2011-04-15T02:57:22.000+00001847849

Comments

  1. dhpublic (at gmail) 2011-04-15

    For quick reference, here are the relevant lines of code.

       var animationStep = 1;
   var animationView = Titanium.UI.createImageView({
    
   
    
   
   
       
   
                       width: 320, height: 385, top: 0});
   
       
   
   
    
   win1.add(animationView);
   
   
    
   function updateAnimationCallback() {
   
   
       animationView.image =
               Ti.Filesystem.getFile(
                      Titanium.Filesystem.resourcesDirectory, 
                      'images/' + animationStep + '.jpg');
   if (animationStep <= 100) {
       animationStep++;
   } else {
       animationStep = 1;
   }
   
       
   
   
    
   }
   
   
    
   setInterval(updateAnimationCallback, 100);
  2. dhpublic (at gmail) 2011-04-15

    Assigned this to Kevin, since he's the one who asked for the ticket on the Q&A.

  3. kevinwhinnery 2011-04-15

    Thanks for creating the test case, that's very helpful.

  4. dhpublic (at gmail) 2011-04-15

    I assume no one's had a chance to look at this?

  5. dhpublic (at gmail) 2011-04-15

    Since I'm not a paying customer, I certainly have no right to complain. But my inability to get answers here or in Q&A tells me I need to abandon the Appcelerator platform.

  6. Stephen Tramer 2012-07-25 Tested SDK 2.2.0.f9e938d, still a valid test case. It is highly likely that this is caused by image caching and disabling it (especially for larger images like the ones in this test) is undesirable. Further investigation outside of scrub is required.
  7. Lee Morris 2017-08-08 Closing due to inactivity. If this issue still exists, please raise a new ticket.

JSON Source