[
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
