JDK-8126829 : invisible and flickering ImageViews when moving along PathTransition and scaling the root parent
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 7u6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-07-11
  • Updated: 2017-05-03
  • Resolved: 2012-07-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
Duplicate :  
Relates :  
Description
In my app I have Nodes moving through PathTransitions.  If I scale the root Parent then the Nodes start disappearing and flickering.

I created some test code to reproduce.  Run the attached file.  Use the UP/DOWN arrows to scale the root Parent.  Use the RIGHT/LEFT arrows to add and remove Nodes to the screen.  To reproduce just add a lot of Nodes to the screen by holding down the RIGHT arrow and then start pressing the UP and DOWN arrow to scale.  You should start seeing the Nodes disappearing.  When this happens adding or removing another Node causes the problem to go away.  a few times a took a minute or two for the problem to kick in, other times i happens right away.

thanks
jose
Comments
the fix that was applied to parent didn't fix this issue for our case. however, the workaround, which adds the following lines to Group#impl_computeGeomBounds: if (!baseTransform.isTranslateOrIdentity()) { super.impl_computeGeomBounds(baseBounds, BaseTransform.IDENTITY_TRANSFORM); } works perfectly. i am not able to reproduce this issue on a small scale, let alone an SSCCE, yet. In our case, essentially, the layoutBounds of shapes are updated over time by using AnimationTimer.
15-08-2013

RT-24091 has been filed to backport the fix for this issue to 2.2.2 (which will ship with JDK 7u8).
08-08-2012

Unfortunately it is too late to get the fix into JavaFX 2.2 or 2.2.1. But I reworked the workaround (attached as RT23351_Workaround.java) and it should be safe to use it with any version of JavaFX now. It creates patched Parent nodes (and uses internal API) only for JavaFX runtimes prior to and including JavaFX 2.2.1. For newer runtimes it simply returns new instances of un-patched Parent nodes and so doesn't require any internal API.
27-07-2012

As noted, the workaround uses internal interfaces and is likely to break with the next major version of JavaFX.
27-07-2012

Lubomir, I request to raise the priority of this issue and have it fixed for the next release, ideally 2.2 The reason is that we are also suffering from this bug and for us it is in fact not a corner case but the common case! We are a quite successful commercial component developer and stumbled upon this problem during the implementation of our POCs for the port of our existing library to JavaFX. A colleague of mine did a nice writeup plus demo and screencast here: https://forums.oracle.com/forums/thread.jspa?threadID=2417478&tstart=30 We would rather not use the workaround because if you decide to make this method final or otherwise incompatibly change the non-public API with respect to the workaround, that would be a real pity, but without the workaround the whole project's quality is so bad (that issue is absolutely essential for our type of application because it involves the simple viewing of data and suddenly data disappears due to that problem) that we cannot release it without the bug being fixed. Please consider the backport to 2.2 - please feel free to send me a PM (is that possible in JIRA? if not just contact me via our website and mention my name) if you cannot discuss this here. Thanks a lot for your support - Sebastian
26-07-2012

I don't think that the fix has any performance impact (only removes lines). As for the workaround it should have only minimal impact. It is true that it calls the super.impl_computeGeomBounds twice (for transformed bounds), but the work done by the first call is cached and so it is not repeated the next time untransformed bounds are requested.
12-07-2012

Thanks for the reply. I will try the fix tonight and if it works then I guess I'm fine, but let me just test it out first. Are there any performance concerns or negatives to implementing the fix that I should be aware of? thanks jose
12-07-2012

1) The workaround should work for any Parent subclass on which you can reproduce this problem. 2) I don't know whether the URL has an external equivalent. Anyway it contains only a diff for the fix. The code which the diff targets is open, so I attached it to this issue. 3) As it is it will go to 3.0 (Lombard). For 2.2, the issue had too low priority (needed at least Major). But I think that if you really need the fix sooner, we can still try to get it into 2.2 (then it needs to pass some extra approval process).
12-07-2012

Changeset: d76ea6579e68 Author: Lubomir Nerad <lubomir.nerad@oracle.com> Date: Thu Jul 12 13:44:04 2012 +0200 URL: http://jfxsrc.us.oracle.com/javafx/3.0/scrum/graphics/rt/rev/d76ea6579e68 Description: Fix for RT-23351: invisible and flickering ImageViews when moving along PathTransition and scaling the root parent Unit test: javafx.scene.Parent_recomputeBounds_Test.transformedBoundsCalculationShouldNotInfluenceUntransformed
12-07-2012

Lubomir, Thank you for your work on this... its much appreciated. I have a few questions. 1) Does the workaround posted in the diff file work for all Parent subclasses or only for Group? 2) In your previous comment you added a URL. The URL does not work for me. Is this an internal URL or it one that I should be able to view? 3) This ticket is marked as resolved, does that mean it will be added to a release? If so which release can I expect it on? thanks again jose
12-07-2012

For workaround check the attached diff file. But it uses internal FX API, so I don't know whether it will be of any use for your project. Anyway, please let me know whether it removed all problems you reported in this issue.
12-07-2012

Besides setting the dirtyopt to false, is there a possible workaround? Would stopping and starting the animation or refreshing the layout help here?
11-07-2012

This problem was introduced by the fix for RT-7154, which added cleaning of Parent.dirtyChildren list into Parent's transformed bounds calculation. This broke any following untransformed bounds calculation which required information from the original dirtyChildren list.
11-07-2012

Taking back my comment, I managed to reproduce the problem also with root group.
11-07-2012

I don't see the flickering reported in description, but I can reproduce soldiers disappearing as if clip was applied on a part of the scene (the last calculated dirty region before transformation) or in other words as if dirty region calculation was frozen and kept giving the same result. This disappears if a Group is used as the root node instead of a Pane. That could be a good workaround for the application.
11-07-2012

It is an issue with dirty rect optimization. The following code is a workaround. > public static void main(String[] args) { > System.setProperty("prism.dirtyopts", "false"); > launch(args); > }
11-07-2012