<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I don't think that's the correct solution, as it opens up a whole
new avenue for subtle bugs, bringing GC/JVM/OS whims and settings
into the mix. We want the clean-up to be easier to reason about,
not harder. <br>
</p>
<p>Even if it were a good idea, it's likely also going to be a
breaking change to add weak references at this stage, without some
kind of opt-in (which would then require new API, in which case we
might as well go for a solution that has no need of weak
references).</p>
<p> I feel I have to keep repeating this, but there almost zero
guarantees made by the JVM or Java with regards to references;
they are fine for internal processes carefully designed to have no
user visible side effects, but burdening the user with side
effects (delayed clean-up, or early unexpected clean-up due to
lack of a hard reference) without the user actually choosing to
use a reference type themselves is not a good design.</p>
<p>--John<br>
</p>
<div class="moz-cite-prefix">On 18/12/2023 17:18, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR1001MB21725E766D642ED1BCD717BDE590A@DM5PR1001MB2172.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16"">Would making Timeline to use WeakReferences
solve the issue without the need for a new API?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">From:
</span></b><span
style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> on behalf of John
Hendrikx <a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a><br>
<b>Date: </b>Friday, December 15, 2023 at 21:53<br>
<b>To: </b>openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>New API: Animation/Timeline
improvement<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:11.0pt">Hi list,<br>
<br>
I've noticed that Animations and Timelines are often a
source of leaks, <br>
and their clean-up is often either non-existent or
incorrect. The <br>
reason they cause leaks easily is because a running
animation or <br>
timeline is globally referred from a singleton
PrimaryTimer. The <br>
animation or timeline then refers to properties or
event handlers which <br>
refer to controls (which refer to parents and the
entire scene).<br>
<br>
For example:<br>
<br>
- ScrollBarBehavior uses a Timeline, but neglects to
clean it up. If it <br>
was running at the time a Scene is detached from a
Window, and that <br>
Scene is left to go out of scope, it won't because
Timeline refers it; <br>
this can happen if the behavior never receives a key
released event.<br>
<br>
- ScrollBarBehavior has no dispose method overridden,
so swapping Skins <br>
while the animation is running will leave a Timeline
active (it uses <br>
Animation.INDEFINITE)<br>
<br>
- SpinnerBehavior has flawed clean up; it attaches a
Scene listener and <br>
disables its timeline when the scene changed, but the
scene doesn't have <br>
to change for it to go out of scope as a whole...
Result is that if you <br>
have a spinner timeline running, and you close the
entire window (no <br>
Scene change happens), the entire Scene will still be
referred. It also <br>
uses an indefinite cycle count. It also lacks a
dispose method, so <br>
swapping Skins at a bad moment can also leave a
reference.<br>
<br>
I think these mistakes are common, and far too easy to
make. The most <br>
common use cases for animations revolve around
modifying properties on <br>
visible controls, and although animations can be used
for purposes other <br>
than animating UI controls, this is extremely rare.
So it is safe to <br>
say that in 99% of cases you want the animation to
stop once a some Node <br>
is no longer showing. For both the mentioned buggy
behaviors above, this <br>
would be perfect. A spinner stops spinning when no
longer showing, and <br>
a scroll bar stops scrolling when no longer showing.
It is also likely <br>
to apply for many other uses of timelines and
animations.<br>
<br>
I therefore want to propose a new API, either on Node
or Animation (or <br>
both):<br>
<br>
/**<br>
* Creates a new timeline which is stopped
automatically when this Node<br>
* is no longer showing. Stopping timelines is
essential as they <br>
may refer<br>
* nodes even after they are no longer used
anywhere, preventing <br>
them from<br>
* being garbage collected.<br>
*/<br>
Node.createTimeline(); // and variants with the
various Timeline <br>
constructors<br>
<br>
And/or:<br>
<br>
/**<br>
* Links this Animation to the given Node, and
stops the animation<br>
* automatically when the Node is no longer
showing. Stopping <br>
animations<br>
* is essential as they may refer nodes even
after they are no <br>
longer used<br>
* anywhere, preventing them from being garbage
collected.<br>
*/<br>
void stopWhenHidden(Node node);<br>
<br>
The above API for Animation could also be provided
through another <br>
constructor, which takes a Node which will it be
linked to.<br>
<br>
Alternatives:<br>
<br>
- Be a lot more diligent about cleaning up animations
and timelines <br>
(essentially maintain the status quo which has led to
above bugs)<br>
- Use this lengthy code fragment below:<br>
<br>
Timeline timeline = new Timeline();<br>
<br>
someNode.sceneProperty()<br>
.when(timeline.statusProperty().map(status
-> status != <br>
Status.STOPPED))<br>
.flatMap(Scene::windowProperty)<br>
.flatMap(Window::showingProperty)<br>
.orElse(false)<br>
.subscribe(showing -> {<br>
if (!showing) timeline.stop();<br>
});<br>
<br>
The `when` line ensures that the opposite problem
(Nodes forever <br>
referencing Timelines) doesn't occur if you are
creating a new Timeline <br>
for each use (not recommended, but nonetheless a
common occurrence).<br>
<br>
--John<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>