Performance Issues when Scale isn't 1.0

[Brent Christian]

Thanks a lot for running that down, Scott.

-Brent

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.
>
> Scott
>
> 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.
>>
>> Scott
>>
>>
>> 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.
>>>
>>> thanks
>>> jose
>>> ------------------------------------------------------------------------
>>> *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.
>>>
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>> 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
>>> >>
>>>
>>>
>>>
>>
>