Closed fthevenet closed 3 years ago
Hi @fthevenet, thanks for the detailed bug report.
I'm not the original author but I am the current maintainer, so if you submit a PR with your suggestion I'll gladly merge it. Otherwise if you could point out the exact code that needs to change I can also submit the PR.
Thanks.
Hi @Jugen
I've submitted PR #82 that should address the issue.
Hello @Jugen
Do you have an ETA for a release that includes this fix (and a subsequent release of RichTextFX)?
As mentioned in the OP, this issue does not manifests itself in versions of JavaFX prior to the upcoming 16. With that said, GA for OpenJFX 16 getting quite close now (planned for March 9, 2021); I think it would be ideal if this could if this could be ready by then. Of course, I'm well aware that there's often a gap in between what's ideal and what's realistic, so hopefully this doesn't come across as pushy.
If I can be of any further assistance on that matter, please let me know.
-- Fred.
Hey Fred, thanks for the prompting .... 0.6.3 has been released now. May take a day or two to appear on Maven though. RichTextFX may follow in the next week or two .....
That's great; thanks a lot!
-- Fred.
Edit: Disregard, I miss-attributed the problem. My issue was another component with an animation that visually did nothing, but kept re-triggering scene layouts.
When using a control embedded inside a
VirtualizedScrollPane
with the upcoming release 16 of JavaFX, then it is possible under specific circumstances that the methodlayoutChildren()
becomes perpetually invoked, causing high CPU and GPU usage even when the application is idle.These conditions are:
The following code sample illustrates the issue, when run under javafx 16, with for instance a 125% scale (you can force it with
-Dglass.win.uiScale=1.25
or-Dglass.gtk.uiScale=1.25
, on windows or linux, respectively):The root cause for this, is that the
VirtualizedScrollPane
request a layout when the height of the horizontal scroll bar changes but in the course and the layout, the calculated value for this height changes, which in turns triggers a request layout, etc...This is due to the fact that a bug was fixed in JavaFX 16 (https://bugs.openjdk.java.net/browse/JDK-8211294) where the mechanism which snaps coordinates to actual pixels on screen with a non integer scale factor was broken; this is now fixed in javaFX, but Flowless remains unaware of the need for enforcing snapping, which causes some coordinates calculated in Flowless to be rounded differently that their equivalent in JavaFX; in this case this is what caused the scrollbar height to be different in two nested calls to
layoutChildren
, and lead to the constant layout.A solution is to use
snapSize()
method to ensure height and width are snapped (i.e. ceil'd) to pixels consistently with JavaFX.(NB: Ideally, we'd want to use
snapSizeX()
andsnapSizeY()
instead of the deprecatedsnapSize()
so that we properly support non square screen ratio, but this is not available in JavaFX 8 that Flowless is built against.)