Performance Issues when Scale isn't 1.0

[Scott Palmer]

No problem.

If anyone takes a look at the test case and knows of a reasonable workaround please update the issue.  I've got a major product to ship, and it will have to go out the door with JavaFX 2.2.  The test case still appears to be usable when it is running slower, but when scaled to my full application the user experience is very bad with the scale transform.

Cheers,

Scott

On 2012-09-24, at 1:14 PM, Brent Christian <brent.christian at oracle.com> wrote:

> 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
>>>> >>
>>>> 
>>>> 
>>>> 
>>> 
>>