JDK-8099062 : PRISM: Strokes are really really really slow
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2009-10-23
  • Updated: 2015-06-16
  • Resolved: 2011-06-14
Related Reports
Relates :  
Description
Creating a shape from text happens fairly quickly, but the draw takes an almost infinite
amount of time. Use the attached program with prism (after making sure you have 
synced to get multi-line support)
Comments
Joe, can u pls confirm if this is still an issue and if not close it? Its moved out of this release.
07-06-2011

var stroke : InnerShadow = InnerShadow { radius: 6 color: Color.RED } adding this to the font adds a red "stroke" very quickly, similar to how it is done in flash.
24-06-2010

There are two ways that strokes are applied to text in flash. 1) The new way (post flash 8), gives near instant results. Applies a glow effect to the text (from what looks it looks like the text is rendered to an image) and the glow is set really high and to a color. Making the glow inner gives another more stroke-like look. This is more common with designers now. 2) break apart the text into individual shapes, and then do it again to break it up into vector shapes. then manually use the ink bottle tool to apply the color manually to each edge of each symbol. This is required for anything flash 8 or before.
23-06-2010

Joe please run this with Flash to see what performance we get
22-06-2010

I tweaked the array allocation once more and got another few orders of improvement for the dashing code. Also, I added code to allocate the Path2D with the appropriate number of segments up front to avoid reallocation garbage when the resulting stroke path is copied into the Path2D. The memory used is still much greater than the memory used for the Swing stack, though. This could be because of the extra copy of the path into the Path2D object (thereby doubling the storage), and it could also be due to less efficient paths generated by the stroking engine. Further work will still be required, but the situation is getting better and better already...
04-11-2009

The performance of the strokepath creation code is almost entirely responsible for the time taken here. A simple change to the array reallocation code in the Prism stroke generator yields about a 10x improvement for stroking lines of text, but for long paragraphs it still takes prohibitively long and we are still far short of the time taken for Swing to do the same operations. A more drastic solution will be needed in the long run, but I am reducing the priority of this bug to Major given the existing improvements.
29-10-2009

This test case also takes a really really long time with the Swing stack - 20 seconds for the window to appear and another 15 seconds for the text to be rendered for a total of around 35 seconds. The prism stack shows the window almost immediately, likely due to a slightly different initialization sequence, but then spends over 2 minutes with nothing showing yet. I reduced the text to a single line and now the Swing stack shows the window and contents almost immediately and the prism stack still takes about a minute to show it all.
29-10-2009