pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger Whitcomb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PIVOT-894) Memory leak when using dataRenderer blocks in bxml files
Date Wed, 20 Feb 2013 17:11:14 GMT

    [ https://issues.apache.org/jira/browse/PIVOT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582336#comment-13582336

Roger Whitcomb commented on PIVOT-894:

Some more comments on what the problem is:
- When creating a <dataRenderer> for a button (for instance) in BXML, a new instance
is created every time you do this, as opposed to the default renderer, which uses a singleton
instance every time.  
- Then, each renderer created has its own ImageView instance, and ImageViewSkin
- When the renderer does "setIcon" on the ImageView, the Image adds the ImageViewSkin as a
listener for image changes, thus making (in the test case (not attached yet)) 1000s and 1000s
of entries in the list for no reason -- the image never changes and these "imageChanged" methods
will never be called.
- The related bug (PIVOT-861) kind of helps this situation by not creating and releasing 1000s
of little ListenerList$Node objects, which clog up memory and make garbage collection work
very hard, but the root problem is still there, and memory continues to be used.
- So, the two possible solutions I see are this:
    - Make BXMLSerializer understand that Renderer objects can be cached, and then make a
"equals" method for them that equates Renderer objects that have the same characteristics
(that is layout and padding, etc.) so that newly created ones that would have the same drawing
effect would also end up being treated as singletons.
    - But note, the test application *could* have solved this by making only one object and
referencing it even in the BXML as a singleton, so doing all this work in the core Pivot code
for a strange test case doesn't seem justified.
    - But also, it seems like the ImageView used by many of the Renderers doesn't need to
get notified of changes to an Image object that will never happen (because the usage of Images
for drawing purposes in a Renderer is essentially a static image, the Renderer itself never
changes the Image it is given, so the possible changes that would get signaled by the ImageListenerList
will never happen.  So, even the source of this memory leak is silly -- there is no need to
create a list to listen for changes that will never happen.
    - So, I propose to create the idea of a "static Image" that would be used by Renderers
that need to draw Images.  Then the ImageViewSkin would never get added to that "static Image"'s
ImageListenerList....  Not sure if this will be a subclass of Image (somehow) or just a flag
and a different method: "Image.setStaticImage()".

Comments??  Thanks.
> Memory leak when using dataRenderer blocks in bxml files
> --------------------------------------------------------
>                 Key: PIVOT-894
>                 URL: https://issues.apache.org/jira/browse/PIVOT-894
>             Project: Pivot
>          Issue Type: Bug
>          Components: wtk, wtk-media
>    Affects Versions: 2.0.2
>            Reporter: Sandro Martini
>            Assignee: Roger Whitcomb
>              Labels: cache, image, leak, listener, memory
>             Fix For: 2.1, 2.0.3
> This is the second part of PIVOT-861, moved here (and so even the related test case).
> For a full solution of this maybe we need some incompatible change (so in this case it
will be moved to 2.1), and maybe even some changes to the test case.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message