Performance Issues when Scale isn't 1.0
brent.christian at oracle.com
Mon Sep 24 10:14:59 PDT 2012
Thanks a lot for running that down, Scott.
On 9/22/12 8:13 AM, Scott Palmer wrote:
> I've managed to isolate a massive performance drop (approx. 100x slower)
> when updating Paths.
> I have created RT-25166 that includes a test case.
> On 2012-09-22, at 10:54 AM, Scott Palmer <swpalmer at gmail.com
> <mailto:swpalmer at gmail.com>> wrote:
>> I've been investigating more and have found that this issue has
>> something to do with modifying Path objects in my scene.
>> The ScrollPane content is a Group wrapped in a Group so the ScrollPane
>> uses the visual bounds instead of the layout bounds. In my Group
>> there are several Path objects that need to be updated - it's updating
>> those Path objects that seems to go over 20 times slower when a scale
>> factor is applied. It's something about updating the Path objects in
>> a ScrollPane with a scale factor. The Path objects end points are
>> updated via layoutChildren in a class derived from Group. The Paths
>> are simple MoveTo, LineTo straight lines… but I'm still trying to
>> isolate a test case.
>> On 2012-09-21, at 10:34 PM, Jose Martinez <jmartine_1026 at yahoo.com
>> <mailto:jmartine_1026 at yahoo.com>> wrote:
>>> I also have reduced performance when scaling not 1.0. I scale the
>>> root node attached to the scene. The scaling performance problems
>>> happen during an animation that occurs often, same labels fading in
>>> and out when certain events occur. I considered this not so much a
>>> bug but just a lot of stuff happening on the screen and eventually I
>>> will hit the limit. The fix I am applying is to get rid of the
>>> fading animation and replace with another indicator that is not as
>>> graphic intensive.
>>> But if there is a bug somewhere or an effort to improve scaling
>>> performance then I will upvote it. Maybe in the future this will
>>> cause a problem that I cannot easily workaround.
>>> *From:* Scott Palmer <swpalmer at gmail.com <mailto:swpalmer at gmail.com>>
>>> *To:* Brent Christian <brent.christian at oracle.com
>>> <mailto:brent.christian at oracle.com>>
>>> *Cc:* "openjfx-dev at openjdk.java.net
>>> <mailto:openjfx-dev at openjdk.java.net>" <openjfx-dev at openjdk.java.net
>>> <mailto:openjfx-dev at openjdk.java.net>>
>>> *Sent:* Friday, September 21, 2012 2:12 PM
>>> *Subject:* Re: Performance Issues when Scale isn't 1.0
>>> Hi Brent,
>>> Yes, that is correct, even when the zoom results in less being drawn
>>> performance drops.
>>> It so happens that I had a go at making this into a Stage-based
>>> "pure" JavaFX application. I hand
>>> t tried that code in a while, as there is a lot more to do to migrate
>>> the entire app, but what we have in our JFXPanel is mostly functional.
>>> Here's the bad news. Performance in the Stage based app is even
>>> worse! I use CTRL+MOUSE_WHEEL for zoom. In the JFXPanel version the
>>> zoom is relatively smooth (we actually animate it a bit via JavaFX to
>>> go from one zoom level to another). In JavaFX I see the zoom happen
>>> at about 1 frame per second!. Dragging the components is at least as
>>> bad as with a JFXPanel, but I'm pretty sure it is worse. I don't
>>> quite get how that can be.
>>> I'm going to do more investigation, as I now suspect an interaction
>>> with the scroll pane. The JFX GUI also has two versions of the
>>> document that are always zoomed out and not part of the scroll pane -
>>> basically to give a birds-eye view of the entire document. They
>>> don't seem to have any effect on the performance.
>>> On 2012-09-21, at 1:05 PM, Brent Christian
>>> <brent.christian at oracle.com <mailto:brent.christian at oracle.com>> wrote:
>>> > Hi, Scott
>>> > I'm not aware of any performance issues specific to scaling.
>>> > You say the problem happens when you zoom in *or* out, so I assume
>>> it's not simply a matter of increased complexity in the visible
>>> portion of the graph.
>>> > I would be interested to know if performance is different with the
>>> UML diagram placed in a Stage instead of a JFXPanel.
>>> > I'm guessing a new JIRA will need to be filed.
>>> > Thanks,
>>> > -Brent
>>> > On 9/21/12 7:51 AM, Scott Palmer wrote:
>>> >> I've searched Jira and didn't find anything. Is there a known
>>> issue with scaling causing significant performance degradation?
>>> >> I have an application that renders something like a UML diagram in
>>> a JFXPanel. Basically it looks like a bunch of rectangles connect by
>>> lines. I can grab and drag those rectangles to layout the document,
>>> which can be rather large. I can also drag new connections between
>>> the boxes. This all works smoothly, until I try to "zoom" in or out
>>> on the diagram.
>>> >> If I set a single X & Y scale factor on the parent node of my
>>> diagram so that I can see more of it (it's in a scrollpane too), that
>>> makes the performance plummet when I drag the boxes or try to drag a
>>> new Path to make a connection. It's at least 5 times slower I
>>> figure. The user experience is horrible as I get less than 5 fps at
>>> times vs. 30+ with the scale set to 1.0
>>> >> I know there is ongoing work with performance, I just wondered if
>>> this is a known issue in 2.2.0 (Jira #?). I would file a bug, but it
>>> would take a while to isolate a test case from my current app.
>>> >> Regards,
>>> >> Scott
More information about the openjfx-dev