• Type: Enhancement
• Component: javafx
• Sub-Component: controls
• Affected Version: fx2.0

• Priority: P3
• Status: Closed
• Resolution: Fixed

• Submitted: 2011-09-09
• Updated: 2015-06-16
• Resolved: 2013-07-15

JDK 8
8Fixed

Verified on 8.0b120. 31-12-2013 I'm closing this problem as fixed as we added code to the GlyphCache to respect the clipping. Further optimization should be done at the controls level (see my last comment). 15-07-2013 As far as I'm concerned I have fixed this problem at the graphics level. During rendering only the visible glyphs are rendered (it relies the clipping set). Note that the Text node has to analyze the entire string to be able to calculate its layout and geometry bounds. If we need to improve the performance for TextArea further we should reassign this problem to Controls. They would need to virtualize the text content created by TextArea (is there a jira for that already ?). 07-05-2013 Results on Windows: D3D pipeline: [java] ------------------------------ [java] Results of running controls.bm.TextAreaBenchmark: [java] Thread 0: 1 results [java] fx.bm.util.MultiScore { [java] JFX_FPS 363.930229 fps greater-is-better [java] JFX_PULSES 385.213684 pulses/sec greater-is-better [java] } [java] SW pipeline [java] ------------------------------ [java] Results of running controls.bm.TextAreaBenchmark: [java] Thread 0: 1 results [java] fx.bm.util.MultiScore { [java] JFX_FPS 57.267673 fps greater-is-better [java] JFX_PULSES 60.413196 pulses/sec greater-is-better [java] } [java] 15-11-2012 I believe this bug too was fixed by RT-14356 I retested "ant run-textarea-bm" On mac, ES2 pipeline: [java] Results of running controls.bm.TextAreaBenchmark: [java] Thread 0: 1 results [java] fx.bm.util.MultiScore { [java] JFX_FPS 255.349731 fps greater-is-better [java] JFX_PULSES 265.891850 pulses/sec greater-is-better [java] } (can't run any other pipeline on mac due RT-25923) 15-11-2012 >If there's a wrapping width set, then we don't need to do this. yes we do to find the height for the text node used in impl_computeLayoutBounds() and impl_computeGeomBounds(). 14-11-2012 > But note that while we can use clipping to stop drawing glyphs once the view is full we will still have to shape to entire string to find out the width for the node. If there's a wrapping width set, then we don't need to do this. 17-08-2012 That is definitely a problem that we will address for 3.0 But note that while we can use clipping to stop drawing glyphs once the view is full we will still have to shape to entire string to find out the width for the node. 10-08-2012 I also observed this behaviour yesterday, with JFX 2.2b18. For my tests I used a more or less random file: https://raw.github.com/clojure/clojure/master/src/clj/clojure/core.clj As of this writing, this file is 6719 and loads instantaneously into Firefox 15 and scrolls perfectly fluid. For my JFX test I used a StackPane and put a ScrollPane inside, which I filled with a javafx.scene.text.Text instance which contained that text above. Also in JFX this scrolls very well. *This* text. But now I concatenated that text String 100x in a row into a single String, which now contained 22269300 chars. This is extremly slow, maybe 0.2 FPS or something like that. The 100x concatenated String I saved to the disk and opened it with the browser. Opening that file took around 10 seconds before it was displayed. But after Firefox displayed it, the scrolling was perfectly fluid. So, for long strings a ScrollPane+Text is unusable. But it should be as fast or faster than the web browser (and this is important in company meetings, when people have HTML5 vs. JFX debates). The same test I made with a TextArea, with the same result. Unusably slow. In principle those components only need render those chars, which are visible at a given time, and not the whole String. 08-08-2012 The entire TextArea is rendered by GlyphCache.render() on every frame, even when a much smaller area is actually visible. This issue appears to be related to RT-14481. 20-09-2011