Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 334367 - Image#dispose() does not unregister its resource from ResourceManager
Summary: Image#dispose() does not unregister its resource from ResourceManager
Status: NEW
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-14 06:11 EST by Rüdiger Herrmann CLA
Modified: 2011-01-14 09:09 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rüdiger Herrmann CLA 2011-01-14 06:11:40 EST
Session-scoped images that are created with on of the Image constructors should free allocated resources when they are disposed. This ssems not to be the case.

The test below fails:
  public void testDisposeUnregistersResource() {
    ClassLoader loader = Fixture.class.getClassLoader();
    InputStream stream = loader.getResourceAsStream( Fixture.IMAGE1 );
    Display display = new Display();
    Image image = new Image( display, stream );
    image.dispose();
    
    String resourceName = image.internalImage.getResourceName();
    IResourceManager instance = ResourceManager.getInstance();
    boolean registered = instance.isRegistered( resourceName );
    assertFalse( registered );
  }
Comment 1 Rüdiger Herrmann CLA 2011-01-14 06:20:25 EST
Is the resource not freed intentionally?
If not, please let me know and I will provide a patch...
Comment 2 Ralf Sternberg CLA 2011-01-14 09:02:50 EST
Maybe I'm missing something, but I think cleaning up is not simple, since Images are just flyweight wrappers around InternalImages. An InternalImage can be used by multiple images / sessions. For example, if session A creates an image and then session B creates an image from the same file/stream/imagedata, both images reference the same internal image. When then session A disposes of the image, the resource can not be de-registered, since session b still uses it.

I think to be able to clean up, we'd first need a cache replacement strategy (bug 332977). What do you think?
Comment 3 Ralf Sternberg CLA 2011-01-14 09:09:09 EST
My last statement was wrong - a cache replacement alone would not help to decide whether an InternalImage is still used. We'd also need to implement some kind of reference counting to do so.

However, images that are frequently used by an application should possibly rather not be de-registered and re-registered all the time, should they?