API Review: Missing UNSORTED Comparator constant in SortedList

[Martin Sladecek]

Hi,
while discussing the SortedList, we were talking about how to return to 
the unsorted state and the proposed solution was to have special 
SortedList.UNSORTED constant for comparator.


Unfortunately, I forgot to include it in the final proposal, so I'm 
proposing this now.


Thanks David Qiao for noticing this ( 
https://javafx-jira.kenai.com/browse/RT-30831).


Thanks,
-Martin

hg: openjfx/8/master/rt: 95 new changesets

[hang . vo]

Changeset: 9134051bb8fb
Author:dmasada
Date:  2013-05-21 13:54 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9134051bb8fb

RT-30002 Ensemble8 - Search box layout is incorrectly enlarged

! apps/samples/Ensemble8/src/app/ensemble/control/SearchBox.java

Changeset: ad014e2245f6
Author:Chien Yang 
Date:  2013-05-21 17:30 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad014e2245f6

Fix to RT-30448: FX 8 3D: Change Mesh's indexBuffer type from unsigned int to 
unsigned short
Reviewed by Dave and Kevin

! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java
! prism-common/src/com/sun/prism/impl/BaseMesh.java
! prism-d3d-native/src/D3DContext.cc
! prism-d3d-native/src/D3DMesh.cc
! prism-d3d-native/src/D3DMesh.h
! prism-d3d/src/com/sun/prism/d3d/D3DContext.java
! prism-d3d/src/com/sun/prism/d3d/D3DMesh.java
! prism-es2-native/src/GLContext.c
! prism-es2/src/com/sun/prism/es2/ES2Context.java
! prism-es2/src/com/sun/prism/es2/ES2Mesh.java
! prism-es2/src/com/sun/prism/es2/GLContext.java

Changeset: a702113db3bb
Author:Radko Najman 
Date:  2013-05-22 15:41 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a702113db3bb

StackPane.layoutChildren() optimization

! javafx-ui-common/src/javafx/scene/layout/StackPane.java

Changeset: 2255fb807e7b
Author:Alexander Zvegintsev
Date:  2013-05-22 20:06 +0400
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2255fb807e7b

RT-30402 Gtk: Ensemble8: DISAPPEAR cursor looks like regular one

! glass/glass-lib-gtk/src/GlassCursor.cpp

Changeset: 99ae05926cc3
Author:David Hill
Date:  2013-05-22 12:25 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/99ae05926cc3

gradle - for Linux move INLINE cflag to appropriate modules

! gradleBuildSrc/linux.gradle

Changeset: 1d31e3a0617e
Author:David Hill
Date:  2013-05-22 17:56 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1d31e3a0617e

gradle - fixing cross builds to artifacts

! build.gradle

Changeset: 7a51619418ec
Author:snorthov
Date:  2013-05-22 18:22 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a51619418ec

fix .classpath

! .classpath

Changeset: 951b878804e0
Author:"Jasper Potts"
Date:  2013-05-22 15:57 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/951b878804e0

3D Viewer App: Added very simple viewer app. Added command line option for 
initial 3D file. Moved obj import to using PolyMesh

+ apps/experiments/3DViewer/src/main/java/META-INF/MANIFEST.MF
! 
apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java
! 
apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/PolyObjImporter.java
! 
apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java
! 
apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java
+ 
apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java

Changeset: bfadff5e8544
Author:Petr Pchelko 
Date:  2013-05-23 11:27 +0400
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bfadff5e8544

RT-30544 Mac: clean up MacSystemClipboard and MacPasteboard classes
Reviewed-by: anthony

! glass/glass-lib-macosx/src/GlassPasteboard.m
! glass/glass/src/com/sun/glass/ui/mac/MacDnDClipboard.java
! glass/glass/src/com/sun/glass/ui/mac/MacPasteboard.java
! glass/glass/src/com/sun/glass/ui/mac/MacSystemClipboard.java

Changeset: e6bf05485e33
Author:Martin Sladecek 
Date:  2013-05-20 14:18 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e6bf05485e33

RT-30392 Stage.setScene and sizing

! javafx-ui-common/src/javafx/stage/Window.java
! javafx-ui-common/test/unit/javafx/scene/SceneTest.java
! javafx-ui-common/test/unit/javafx/stage/StageTest.java
! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java

Changeset: 9d7dd36b9f4f
Author:Martin Sladecek 
Date:  2013-05-20 14:19 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9d7dd36b9f4f

Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfxrt


Changeset: db64797fc2eb
Author:Martin Sladecek 
Date:  2013-05-23 11:11 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/db64797fc2eb

RT-26821 FlowPane / BorderPane doesn't layout properly when FlowPane doesn't 
have enough room to fit

! javafx-ui-common/src/javafx/scene/layout/BorderPane.java
! javafx-ui-common/test/unit/javafx/scene/layout/BorderPaneTest.java

Changeset: ad208e3eb53e
Author:Martin Sladecek 
Date:  2013-05-23 11:13 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad208e3eb53e

merge


Changeset: 26bdb2990130
Author:Martin Sladecek 
Date:  2013-05-23 11:13 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26bdb2990130

Automated merge with 
ssh://jfxsrc.us.oracle.c

Re: JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

Here is pretty much the same animation in JavaScript of the animated box:
http://www.zenjava.com/demo/animate1.html

While it's not perfect, on my system (Google Chrome, Windows 7, Dell
Latitude E6520) the visual appearance is noticeably better than the JavaFX
one. For example there is no shimmering of the borders (there's an ever so
slight jitter but it's far less noticeable than the JFX 'shimmer'). The
text also seems more crisp in the JavaScript one in my system (without
setting any magic caching settings).

I don't know if its pixel snapping or crack jamming, or whatever else the
options are, but it does look noticeably better in my web browser than my
native desktop app. I'm hoping JavaScript level performance (or whatever
you want to call it) is a pretty low bar to be aiming for?

The drop shadow is not great in either system. It looks slightly better on
the JScript one but that may be because it is darker and bigger in this
sample.




On Fri, May 31, 2013 at 2:36 PM, Richard Bair wrote:

> Thanks for the issues! As mentioned in RT-30830 and RT-30827, the jittery
> text and fuzzy lines are two manifestations of the same thing. When
> animating, you have two choices. Do you draw everything on pixel
> boundaries, or do you draw "in the cracks" between the pixels? Of course
> the only way to draw between pixels is to draw antialiased on the pixels on
> both sides of the "crack", leaving things blurry.
>
> By default all Text is drawn pixel aligned in order to be crisp (more or
> less -- Windows & Mac may have different answers on this point). So when it
> is animated, it looks like it is jiggling (it is) because each glyph is
> figuring out whether it ought to go left or right. Text nodes are supposed
> to allow you to break out of this behavior for the sake of animation (there
> are a few issues related: RT-23580, RT-6475), but it looks like the way I
> would have tried (cache=true, cacheHint=SPEED) doesn't draw anything in
> this case, and we need to figure out why.
>
> However expect that you will need to do *something* to Text to tell it
> whether you care about animation smoothness or static crispness with the
> text, so that we can be sure to layout the glyphs optimally for your use
> case.
>
> The fuzzy lines on the other hand are perfectly normal and expected. You
> could of course write your app to pixel-snap the animated rectangles, and
> then see if it looks jittery or not (likely, yes).
>
> The Canvas bug is very interesting, and we'll get to the bottom of it.
>
> Thanks
> Richard
>
> On May 30, 2013, at 8:09 PM, Daniel Zwolenski  wrote:
>
> A little bit more esoteric, but some "not very nice looking" rendering
> when animating a very lightly styled Node:
> https://javafx-jira.kenai.com/browse/RT-30830
>
>
> On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski wrote:
>
>> Jittery text when scaling in an animation:
>> https://javafx-jira.kenai.com/browse/RT-30827
>>
>>
>> On Fri, May 31, 2013 at 12:01 PM, Richard Bair 
>> wrote:
>>
>>> Wow. Thanks!
>>>
>>> On May 30, 2013, at 6:48 PM, Daniel Zwolenski  wrote:
>>>
>>> I have replicated the z-order problem with the Tower Defender game and
>>> the Canvas: https://javafx-jira.kenai.com/browse/RT-30826
>>>
>>>
>>> On Fri, May 31, 2013 at 1:26 AM, Richard Bair 
>>> wrote:
>>>
 Note this is only for Mac.

 On May 30, 2013, at 7:54 AM, Richard Bair 
 wrote:

 > Anybody interested in jitter ought to look at
 https://javafx-jira.kenai.com/browse/RT-26702
 >
 > Richard


>>>
>>>
>>
>
>

Re: JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Thanks for the issues! As mentioned in RT-30830 and RT-30827, the jittery text 
and fuzzy lines are two manifestations of the same thing. When animating, you 
have two choices. Do you draw everything on pixel boundaries, or do you draw 
"in the cracks" between the pixels? Of course the only way to draw between 
pixels is to draw antialiased on the pixels on both sides of the "crack", 
leaving things blurry.

By default all Text is drawn pixel aligned in order to be crisp (more or less 
-- Windows & Mac may have different answers on this point). So when it is 
animated, it looks like it is jiggling (it is) because each glyph is figuring 
out whether it ought to go left or right. Text nodes are supposed to allow you 
to break out of this behavior for the sake of animation (there are a few issues 
related: RT-23580, RT-6475), but it looks like the way I would have tried 
(cache=true, cacheHint=SPEED) doesn't draw anything in this case, and we need 
to figure out why.

However expect that you will need to do *something* to Text to tell it whether 
you care about animation smoothness or static crispness with the text, so that 
we can be sure to layout the glyphs optimally for your use case.

The fuzzy lines on the other hand are perfectly normal and expected. You could 
of course write your app to pixel-snap the animated rectangles, and then see if 
it looks jittery or not (likely, yes). 

The Canvas bug is very interesting, and we'll get to the bottom of it.

Thanks
Richard

On May 30, 2013, at 8:09 PM, Daniel Zwolenski  wrote:

> A little bit more esoteric, but some "not very nice looking" rendering when 
> animating a very lightly styled Node: 
> https://javafx-jira.kenai.com/browse/RT-30830
> 
> 
> On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski  wrote:
> Jittery text when scaling in an animation: 
> https://javafx-jira.kenai.com/browse/RT-30827
> 
> 
> On Fri, May 31, 2013 at 12:01 PM, Richard Bair  
> wrote:
> Wow. Thanks!
> 
> On May 30, 2013, at 6:48 PM, Daniel Zwolenski  wrote:
> 
>> I have replicated the z-order problem with the Tower Defender game and the 
>> Canvas: https://javafx-jira.kenai.com/browse/RT-30826
>> 
>> 
>> On Fri, May 31, 2013 at 1:26 AM, Richard Bair  
>> wrote:
>> Note this is only for Mac.
>> 
>> On May 30, 2013, at 7:54 AM, Richard Bair  wrote:
>> 
>> > Anybody interested in jitter ought to look at 
>> > https://javafx-jira.kenai.com/browse/RT-26702
>> >
>> > Richard
>> 
>> 
> 
> 
> 

Re: Backwards compatibility issue?

[Daniel Zwolenski]

No stack trace, just this:

C:\temp>c:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar
Cannot add stylesheet. 512

If there's an easy way to turn on more debugging info let me know.



On Fri, May 31, 2013 at 2:07 PM, Richard Bair wrote:

> Possibly, what is the stack trace?
>
> On May 30, 2013, at 8:24 PM, Daniel Zwolenski  wrote:
>
> > While trying to narrow down the rendering/performance/whatever issues
> with
> > the game, I just opened up the JAR that I'd previously built for it:
> > https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar
> >
> > If I run this with java version "1.7.0_13" it works fine.
> >
> > If I run this with java version "1.7.0_21" none of the styles get loaded.
> >
> > Massive backwards compatibility fail between minor build versions?
>
>

Re: Backwards compatibility issue?

[Richard Bair]

Possibly, what is the stack trace?

On May 30, 2013, at 8:24 PM, Daniel Zwolenski  wrote:

> While trying to narrow down the rendering/performance/whatever issues with
> the game, I just opened up the JAR that I'd previously built for it:
> https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar
> 
> If I run this with java version "1.7.0_13" it works fine.
> 
> If I run this with java version "1.7.0_21" none of the styles get loaded.
> 
> Massive backwards compatibility fail between minor build versions?

Backwards compatibility issue?

[Daniel Zwolenski]

While trying to narrow down the rendering/performance/whatever issues with
the game, I just opened up the JAR that I'd previously built for it:
https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar

If I run this with java version "1.7.0_13" it works fine.

If I run this with java version "1.7.0_21" none of the styles get loaded.

Massive backwards compatibility fail between minor build versions?

Re: JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

A little bit more esoteric, but some "not very nice looking" rendering when
animating a very lightly styled Node:
https://javafx-jira.kenai.com/browse/RT-30830


On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski  wrote:

> Jittery text when scaling in an animation:
> https://javafx-jira.kenai.com/browse/RT-30827
>
>
> On Fri, May 31, 2013 at 12:01 PM, Richard Bair wrote:
>
>> Wow. Thanks!
>>
>> On May 30, 2013, at 6:48 PM, Daniel Zwolenski  wrote:
>>
>> I have replicated the z-order problem with the Tower Defender game and
>> the Canvas: https://javafx-jira.kenai.com/browse/RT-30826
>>
>>
>> On Fri, May 31, 2013 at 1:26 AM, Richard Bair wrote:
>>
>>> Note this is only for Mac.
>>>
>>> On May 30, 2013, at 7:54 AM, Richard Bair 
>>> wrote:
>>>
>>> > Anybody interested in jitter ought to look at
>>> https://javafx-jira.kenai.com/browse/RT-26702
>>> >
>>> > Richard
>>>
>>>
>>
>>
>

Re: Patches for packager tweaks

[Danno Ferrin]

I have an OCA signed and in force:
http://www.oracle.com/technetwork/community/oca-486395.html#f

If my statement seemed a little cynical with the subtext being a concern
about whether or not OpenJFX is even interested interested in some of these
patches, that's because it was.

I have two bugs, for things which are obviously broken, with patches that
have not had as far as I can tell any serious consideration.  In fact one
of the bugs has been seen by the SceneBuilder team for their linux install,
and tagged as an importint bug for them!

https://javafx-jira.kenai.com/browse/RT-27989
https://javafx-jira.kenai.com/browse/RT-27984

A bug without a solution is one thing, but these come with fixes.  And they
have been sitting with a patch for over five months now!  Seriously, after
five months I consider these informally rejected, except that the packager
branch hasn't seen much work in that time frame anyway.

I would like to be contributing more but the benign neglect I am seeing
towards my code contributions makes me re-think what I should be doing with
my free time.  Even a formal rejection would be better.

On Thu, May 30, 2013 at 8:08 PM, Kevin Rushforth  wrote:

> **
> Right. I was answering the general question.
>
> For the specific question, I will defer to Mark Howe, who is working on
> the packager.
>
> -- Kevin
>
>
>
> Daniel Zwolenski wrote:
>
> I'm guessing Danno would like to know how long he should expect to wait
> for the patches he kindly contributed and linked to in that email to get
> included. Seems like a fair and reasonable question and one I'd also like
> to know the answer to.
>
>  Perhaps a linked question that I'd also like to know: is anyone actually
> allocated to any work on the packager at the moment, and if not when are
> they next going to be?
>
>
> On Fri, May 31, 2013 at 11:44 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>>
>>  How long is it taking for community patches to get into a build these
>>> days?
>>>
>>
>>  Hi Danno,
>>
>> There are two parts to the answer:
>>
>> 1) How long does it take for a proposed fix (patch) to be reviewed and
>> accepted?
>>
>> 2) Once your patch is accepted and the changeset is pushed to the repo,
>> how long before it shows up in an EA build?
>>
>> #1 depends on what area it is, what is the scale of the proposed change:
>> is it a simple bug fix, or a new feature with API or documentation
>> implications, are there compatibility concerns, how risky is it, etc.
>>
>> #2 is typically between 0.5 and 1.5 weeks depending when it is pushed.
>>
>> As a reminder (Richard may have recently posted something about this, so
>> my apologies if this is a duplicate reminder), anyone submitting a patch
>> must first sign the Oracle Contributor Agreement (OCA) before we can
>> consider taking it.
>>
>> -- Kevin
>>
>>
>>
>>
>> Danno Ferrin wrote:
>>
>>> Just posted to bugs with patches for some tweaks I'de like to see to the
>>> packager.
>>>
>>> https://javafx-jira.kenai.com/browse/RT-30792
>>> https://javafx-jira.kenai.com/browse/RT-30793
>>>
>>> The first one is to allow for a comma separated list of enumerated
>>> packagers, so it's not one or all.
>>>
>>> The second one is more relevant, it moves the discovery of the bundlers
>>> from being hard coded in the class file to loaded off of the
>>> META-INF/services directory.  This allows a bunlder to be added at
>>> "runtime" when the build is being done.  For example, a bundler that
>>> would
>>> bundle RoboVM or APK files provided at runtime rather than having to
>>> package it's reference into the source code itself.
>>>
>>> How long is it taking for community patches to get into a build these
>>> days?
>>>
>>>
>>
>

Re: Patches for packager tweaks

[Kevin Rushforth]

Right. I was answering the general question.

For the specific question, I will defer to Mark Howe, who is working on 
the packager.


-- Kevin


Daniel Zwolenski wrote:
I'm guessing Danno would like to know how long he should expect to 
wait for the patches he kindly contributed and linked to in that email 
to get included. Seems like a fair and reasonable question and one I'd 
also like to know the answer to. 

Perhaps a linked question that I'd also like to know: is anyone 
actually allocated to any work on the packager at the moment, and if 
not when are they next going to be?  



On Fri, May 31, 2013 at 11:44 AM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:



How long is it taking for community patches to get into a
build these days?


Hi Danno,

There are two parts to the answer:

1) How long does it take for a proposed fix (patch) to be reviewed
and accepted?

2) Once your patch is accepted and the changeset is pushed to the
repo, how long before it shows up in an EA build?

#1 depends on what area it is, what is the scale of the proposed
change: is it a simple bug fix, or a new feature with API or
documentation implications, are there compatibility concerns, how
risky is it, etc.

#2 is typically between 0.5 and 1.5 weeks depending when it is pushed.

As a reminder (Richard may have recently posted something about
this, so my apologies if this is a duplicate reminder), anyone
submitting a patch must first sign the Oracle Contributor
Agreement (OCA) before we can consider taking it.

-- Kevin




Danno Ferrin wrote:

Just posted to bugs with patches for some tweaks I'de like to
see to the
packager.

https://javafx-jira.kenai.com/browse/RT-30792
https://javafx-jira.kenai.com/browse/RT-30793

The first one is to allow for a comma separated list of enumerated
packagers, so it's not one or all.

The second one is more relevant, it moves the discovery of the
bundlers
from being hard coded in the class file to loaded off of the
META-INF/services directory.  This allows a bunlder to be added at
"runtime" when the build is being done.  For example, a
bundler that would
bundle RoboVM or APK files provided at runtime rather than
having to
package it's reference into the source code itself.

How long is it taking for community patches to get into a
build these days?
 

Re: JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

Jittery text when scaling in an animation:
https://javafx-jira.kenai.com/browse/RT-30827


On Fri, May 31, 2013 at 12:01 PM, Richard Bair wrote:

> Wow. Thanks!
>
> On May 30, 2013, at 6:48 PM, Daniel Zwolenski  wrote:
>
> I have replicated the z-order problem with the Tower Defender game and the
> Canvas: https://javafx-jira.kenai.com/browse/RT-30826
>
>
> On Fri, May 31, 2013 at 1:26 AM, Richard Bair wrote:
>
>> Note this is only for Mac.
>>
>> On May 30, 2013, at 7:54 AM, Richard Bair 
>> wrote:
>>
>> > Anybody interested in jitter ought to look at
>> https://javafx-jira.kenai.com/browse/RT-26702
>> >
>> > Richard
>>
>>
>
>

Re: JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Wow. Thanks!

On May 30, 2013, at 6:48 PM, Daniel Zwolenski  wrote:

> I have replicated the z-order problem with the Tower Defender game and the 
> Canvas: https://javafx-jira.kenai.com/browse/RT-30826
> 
> 
> On Fri, May 31, 2013 at 1:26 AM, Richard Bair  wrote:
> Note this is only for Mac.
> 
> On May 30, 2013, at 7:54 AM, Richard Bair  wrote:
> 
> > Anybody interested in jitter ought to look at 
> > https://javafx-jira.kenai.com/browse/RT-26702
> >
> > Richard
> 
> 

Re: Patches for packager tweaks

[Daniel Zwolenski]

I'm guessing Danno would like to know how long he should expect to wait for
the patches he kindly contributed and linked to in that email to get
included. Seems like a fair and reasonable question and one I'd also like
to know the answer to.

Perhaps a linked question that I'd also like to know: is anyone actually
allocated to any work on the packager at the moment, and if not when are
they next going to be?


On Fri, May 31, 2013 at 11:44 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

>
>  How long is it taking for community patches to get into a build these
>> days?
>>
>
> Hi Danno,
>
> There are two parts to the answer:
>
> 1) How long does it take for a proposed fix (patch) to be reviewed and
> accepted?
>
> 2) Once your patch is accepted and the changeset is pushed to the repo,
> how long before it shows up in an EA build?
>
> #1 depends on what area it is, what is the scale of the proposed change:
> is it a simple bug fix, or a new feature with API or documentation
> implications, are there compatibility concerns, how risky is it, etc.
>
> #2 is typically between 0.5 and 1.5 weeks depending when it is pushed.
>
> As a reminder (Richard may have recently posted something about this, so
> my apologies if this is a duplicate reminder), anyone submitting a patch
> must first sign the Oracle Contributor Agreement (OCA) before we can
> consider taking it.
>
> -- Kevin
>
>
>
>
> Danno Ferrin wrote:
>
>> Just posted to bugs with patches for some tweaks I'de like to see to the
>> packager.
>>
>> https://javafx-jira.kenai.com/**browse/RT-30792
>> https://javafx-jira.kenai.com/**browse/RT-30793
>>
>> The first one is to allow for a comma separated list of enumerated
>> packagers, so it's not one or all.
>>
>> The second one is more relevant, it moves the discovery of the bundlers
>> from being hard coded in the class file to loaded off of the
>> META-INF/services directory.  This allows a bunlder to be added at
>> "runtime" when the build is being done.  For example, a bundler that would
>> bundle RoboVM or APK files provided at runtime rather than having to
>> package it's reference into the source code itself.
>>
>> How long is it taking for community patches to get into a build these
>> days?
>>
>>
>

Re: JavaFX graphics performance and suitability for advanced animations

[Daniel Zwolenski]

I have replicated the z-order problem with the Tower Defender game and the
Canvas: https://javafx-jira.kenai.com/browse/RT-30826


On Fri, May 31, 2013 at 1:26 AM, Richard Bair wrote:

> Note this is only for Mac.
>
> On May 30, 2013, at 7:54 AM, Richard Bair  wrote:
>
> > Anybody interested in jitter ought to look at
> https://javafx-jira.kenai.com/browse/RT-26702
> >
> > Richard
>
>

Re: Patches for packager tweaks

[Kevin Rushforth]

How long is it taking for community patches to get into a build these days?


Hi Danno,

There are two parts to the answer:

1) How long does it take for a proposed fix (patch) to be reviewed and 
accepted?


2) Once your patch is accepted and the changeset is pushed to the repo, 
how long before it shows up in an EA build?


#1 depends on what area it is, what is the scale of the proposed change: 
is it a simple bug fix, or a new feature with API or documentation 
implications, are there compatibility concerns, how risky is it, etc.


#2 is typically between 0.5 and 1.5 weeks depending when it is pushed.

As a reminder (Richard may have recently posted something about this, so 
my apologies if this is a duplicate reminder), anyone submitting a patch 
must first sign the Oracle Contributor Agreement (OCA) before we can 
consider taking it.


-- Kevin



Danno Ferrin wrote:

Just posted to bugs with patches for some tweaks I'de like to see to the
packager.

https://javafx-jira.kenai.com/browse/RT-30792
https://javafx-jira.kenai.com/browse/RT-30793

The first one is to allow for a comma separated list of enumerated
packagers, so it's not one or all.

The second one is more relevant, it moves the discovery of the bundlers
from being hard coded in the class file to loaded off of the
META-INF/services directory.  This allows a bunlder to be added at
"runtime" when the build is being done.  For example, a bundler that would
bundle RoboVM or APK files provided at runtime rather than having to
package it's reference into the source code itself.

How long is it taking for community patches to get into a build these days?
  

hg: openjfx/8/controls/rt: 3 new changesets

[hang . vo]

Changeset: a92e5afc944b
Author:jgiles
Date:  2013-05-31 10:57 +1200
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a92e5afc944b

RT-30825: Can't Reorder Columns in Table

! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java
! javafx-ui-controls/test/javafx/scene/control/TableColumnTest.java
! javafx-ui-controls/test/javafx/scene/control/TreeTableColumnTest.java

Changeset: 30e3bcb6c736
Author:jgiles
Date:  2013-05-31 11:44 +1200
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/30e3bcb6c736

RT-30398: CheckBox cell factory renders check boxes in empty cells

! javafx-ui-controls/src/javafx/scene/control/ListCell.java
! javafx-ui-controls/src/javafx/scene/control/TableCell.java
! javafx-ui-controls/src/javafx/scene/control/TreeCell.java
! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java
! 
javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java
! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java
! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java
! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java
! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java

Changeset: 7a327e81151a
Author:jgiles
Date:  2013-05-31 12:45 +1200
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a327e81151a

Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt

Re: [API Review] RT-15314

[Daniel Zwolenski]

+1 on system property only at this stage.
+1 on John's comment about escape key.


On Fri, May 31, 2013 at 4:23 AM, John Hendrikx  wrote:

> Does "fullScreenWarning=false" imply also that the escape key would be
> free for normal use?  Removing the overlay is definitely good, but for apps
> that always run full-screen they shouldn't react to escape either.
>
> --John
>
>
> On 29/05/2013 23:51, David Hill wrote:
>
>>
>> We have a request 
>> >
>> to allow non-sandboxed applications to disable the "ESC to exit full
>> screen" overly (and the associated ESC action to exit Full Screen).
>>
>> This is needed for "kiosk" style applications where Full Screen should
>> only be under programmatic control.
>>
>> I have several options to present, but all of them have an underlying
>> change, which is the addition of a system property to disable the overlay
>> behavior:
>> -Djavafx.fullScreenWarning=**false
>>
>> API Option One: Add to Platform, providing for a system toggle that is
>> static.
>>   public static void setFullScreenWarning(boolean warn)
>>   public static boolean getFullScreenWarning()
>>
>> Note: I considered other options, like Application, but felt they were
>> poor fits. I am willing to listen to reason though.
>>
>> API Option Two: Add to Stage. This would be a per instance change, and
>> not a global toggle:
>>   public void setFullScreenWarning(boolean warn)
>>   public boolean getFullScreenWarning()
>>
>> API Option Three: don't change the API at this point, rely only on the
>> system properly to disable the overlay.
>>
>> Note: option three seems to be a reasonable solution for many of the
>> users of this functionality, because in a "kiosk" style application you can
>> control the launching anyway.
>>
>>
>

hg: openjfx/8/graphics/rt: RT-30823: Improve subpixel support for CoreText

[hang . vo]

Changeset: 18da8c32f363
Author:Felipe Heidrich 
Date:  2013-05-30 14:54 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18da8c32f363

RT-30823: Improve subpixel support for CoreText

! prism-common/src/com/sun/prism/impl/GlyphCache.java
! prism-ps/src/com/sun/prism/impl/ps/BaseShaderGraphics.java

hg: openjfx/8/graphics/rt: RT-28953 - JSException should conserve the original exception

[hang . vo]

Changeset: 9b21f61edda7
Author:Per Bothner 
Date:  2013-05-30 13:03 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b21f61edda7

RT-28953 - JSException should conserve the original exception

! javafx-ui-common/src/com/sun/webkit/dom/JSObject.java
! webview/native/Source/WebCore/bridge/jni/jsc/JavaInstanceJSC.cpp
! webview/native/Source/WebCore/platform/java/BridgeUtils.cpp
! webview/test/javafx/scene/web/JavaScriptBridgeTest.java

Re: [API REVIEW] RT-30576 Parent : add new public layout method, optimized to only layout this parent and it's children.

[Richard Bair]

Should this instead be a protected method rather than a public method?

On May 22, 2013, at 7:18 AM, mick.fleming  wrote:

> 
> Hi All,
> 
> this request is to add a method to javafx.scene.Parent
> which only requests a re-layout on the parent and it's
> children.
> 
> The current requestLayout method in Parent clears the
> size cache and requests the layout of all Parents in the
> containment hierarchy. This can be unnecessary if the
> change is contained within the requesting node, and
> there is no change to it's external size, or min/max/pref
> size. A good example of this is that currently an internal
> change to a table-cell could cause an entire table to
> re-layout.
> 
> In order to solve this we could have an additional method in
> Parent which only requests the layout of the current parent
> node and it's children.
> 
> There is a significant performance gain in Table benchmarks
> when this is used in cases where it is known that there are
> no changes to either the cells dimensions or min/max/preferred
> size.
> 
> The current proposed name for this is :
>  public void requestLocalLayout()
> but suggestions are welcome, especially if they
> are more meaningful.
> 
> The jira can be found at :
> https://javafx-jira.kenai.com/browse/RT-30576
> 
> regards,
> mick
> 
> 

Re: [API Review] RT-15314

[John Hendrikx]

Does "fullScreenWarning=false" imply also that the escape key would be 
free for normal use?  Removing the overlay is definitely good, but for 
apps that always run full-screen they shouldn't react to escape either.


--John

On 29/05/2013 23:51, David Hill wrote:


We have a request  to 
allow non-sandboxed applications to disable the "ESC to exit full 
screen" overly (and the associated ESC action to exit Full Screen).


This is needed for "kiosk" style applications where Full Screen should 
only be under programmatic control.


I have several options to present, but all of them have an underlying 
change, which is the addition of a system property to disable the 
overlay behavior:

-Djavafx.fullScreenWarning=false

API Option One: Add to Platform, providing for a system toggle that is 
static.

  public static void setFullScreenWarning(boolean warn)
  public static boolean getFullScreenWarning()

Note: I considered other options, like Application, but felt they were 
poor fits. I am willing to listen to reason though.


API Option Two: Add to Stage. This would be a per instance change, and 
not a global toggle:

  public void setFullScreenWarning(boolean warn)
  public boolean getFullScreenWarning()

API Option Three: don't change the API at this point, rely only on the 
system properly to disable the overlay.


Note: option three seems to be a reasonable solution for many of the 
users of this functionality, because in a "kiosk" style application 
you can control the launching anyway.

hg: openjfx/8/controls/rt: RT-30547: DatePicker doesn't allow to omit leading zero

[hang . vo]

Changeset: e0145393ceaa
Author:leifs
Date:  2013-05-30 10:52 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e0145393ceaa

RT-30547: DatePicker doesn't allow to omit leading zero

! javafx-ui-controls/src/javafx/scene/control/DatePicker.java

Re: JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Note this is only for Mac.

On May 30, 2013, at 7:54 AM, Richard Bair  wrote:

> Anybody interested in jitter ought to look at 
> https://javafx-jira.kenai.com/browse/RT-26702
> 
> Richard

Re: JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Hi John,

> Graphics?  Yes, to a point.  But my post was really about graphics and the
> issues related to performance.  Again, unless those issues are resolved then
> it's not appropriate to state that JavaFX is suitable for "graphics".

You asked what the "full range of applications for which JavaFX is or will be 
suitable for".

> Then you mention Halo 5.  I have to say the subtext here troubles me
> greatly.  If I read you correctly then you are saying that JavaFX is not
> really suitable for games (at least anything beyond the demands of something
> like Solitaire).  As someone else pointed out, what is point of developing
> 3D support in JavaFX if it is not really suitable for games?  To say it is
> not suitable for games implies that it is not really suitable for *any*
> application that requires performant animations and visualisations.  What
> use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D, and 
we get these requests all the time. Whether we're taking about 3D 
visualizations for medical or engineering applications or consumer applications 
(product display, etc), there is a requirement for 3D that are broader than 
real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of 
them) as well as very specialized tricks for getting the most out of their 
graphics cards. When we expose API that allows people to hammer the card 
directly, then it would be possible for somebody to build some of the UI in FX 
and let their game engine be hand written (in Unity or JOGL or whatever).

>>> 4.   Is JavaFX more targeted at form-based UIs rather than high
>>> performance graphics?
>> 
>> No.
> 
> Again, good to know but where are all the high-performance JavaFX apps?  So
> far I have seen nothing but form-based apps.  Wouldn't it be prudent for
> Oracle to include a "showcase" app or game that shows us the full
> capabilities of JavaFX with high-performance graphics?
> 
> I am sure I am not alone in feeling that the animation examples in Ensemble
> do very little to promote the graphics capabilities of JavaFX.

Are you offering to contribute? :-)

>> Are your slow examples reproducible? If so we need the test case. Is there
> an issue filed? We can't fix things we can't reproduce.
>> We spend a *considerable* amount of time and energy on performance and for
> the things we're measuring we're doing well.
>> As the saying goes "what's measured, improves". After the switch to gradle
> and the new project layout, one thing I'm going to
>> look at is using JMH[2] in OpenJFX so we can write micro benchmarks and
> have them easy for everybody to run and 
>> contribute to. Our current set of micro benchmarks are based on the
> predecessor of JMH which was the
>> JRockit benchmark suite and was proprietary (hence we cannot just open
> source our existing benchmarks without doing some rewrite).
> 
> All good points.
> 
> However, I am not sure that having me preparing "reproducible" test cases
> will actually help.  In my experience, the Ensemble app already serves this
> purpose.  The choppiness I describe is *always* prevalent when I run the
> animations and transitions in Ensemble (including Ensemble 8).  The only
> variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation or 
rotate transition and lets figure out how to measure the jitter and get it into 
our benchmark suite.

Richard

hg: openjfx/8/graphics/rt: iOS: Checking available JNI_VERSION @ runtime to be able to run with various JDK8 mobile promotions

[hang . vo]

Changeset: b17e961ecd38
Author:Oldrich Maticka 
Date:  2013-05-30 16:54 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b17e961ecd38

iOS: Checking available JNI_VERSION @ runtime to be able to run with various 
JDK8 mobile promotions

! glass/glass-lib-ios/src/GlassApplication.m
! javafx-iio-native/src/ios/com_sun_javafx_iio_ios_IosImageLoader.m
! javafx-iio-native/src/jpegloader.c
! prism-common-native/src/Helpers.c
! prism-es2-native/src/ios/IOSGLFactory.c

Re: JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Anybody interested in jitter ought to look at 
https://javafx-jira.kenai.com/browse/RT-26702

Richard

On May 29, 2013, at 5:18 PM, Richard Bair  wrote:

> 
>> As ever, just a suggestion. I'll leave it at that so we can get back to the 
>> real issues. 
> 
> 
> So, back to the real issues :-). Here is a good JIRA query:
> 
> https://javafx-jira.kenai.com/issues/?filter=12938&jql=project%20%3D%20RT%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20performance%20ORDER%20BY%20key%20ASC%2C%20priority%20DESC
> 
> I see 228 issues (you might see fewer if they are marked internal, but I 
> can't imagine many if any should be internal). I am (painfully) going through 
> each one and categorizing them, such as:
> 
> G Salami
> B Targeted Win
> R Major Win
> 
> Decora:
> B RT-2892: Improve performance of Gaussian-based effects
> B RT-2908: Use scaled kernel to improve DropShadow performance for node scale 
> factors < 1
> B RT-5347: Prism: finish drop/inner shadow optimizations
> B RT-5420: DropShadow effects significantly affect performance
> B RT-6935: ColorAdjust effect consumes a lot of memory which could lead to 
> OOM exception
> B RT-8890: Merge and some Blend effects should optimize rendering to 
> destination
> 
> Text:
> B RT-5069: Text node computes complete text layout, even if clipped to a much 
> smaller size
> 
> Scene Graph:
> G RT-5525: Group will get bounds change notification when child's bounds 
> change, even if change in child didn't alter bounds of Group
> 
> Prism:
> G RT-5835: Fix for RT-5788 disabled an optimization for anti-aliased 
> rectangles
> B RT-6968: Prism should support 2-byte gray-alpha .png format
> B RT-8722: Strokes and fills of Paths slower than flash
> 
> Threading:
> R RT-2893: Enable multi-threaded processing of software-based effects when >= 
> 2 cores available
> 
> Benchmarks:
> G RT-7644: Math.floor and Math.ceil take up a lot of cpu time
> 
> The colors probably won't come through, so I marked them as "G" to mean 
> "Green", "B" for Blue, "R" for Red. Anyway, I am breaking down the issues 
> first by area (Threading, Scene Graph, etc) and then by type. "Salami" is 
> "death by a thousand cuts" -- something that you fix because you should, but 
> you aren't going to see anything from it unless it is getting executed a 
> BAZILLION times. "Targeted Win" means that if you were to write a micro 
> benchmark that just exercised this one code path and did it heavily (like 
> having 18,000 rectangles with drop shadows or whatever), then fixing this 
> issue would result in a significant improvement in that benchmark. "Major 
> Win" is something that would pretty much across the board have a major 
> positive impact on performance.
> 
> So I've only gone through 15 or so issues (closed a couple of them) of the 
> 220+, so I've got a long way to go. Once I've categorized these, I'll add the 
> different issues to the wiki 
> (https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas)  and link 
> to the most prominent JIRA issues. I'm not going to keep the wiki up to date 
> as new issues are filed as that would be a constant effort -- the wiki will 
> have a link to a JIRA query that will do that. But what I can do is update 
> all the JIRA issues so that they are tagged with "salami", "targeted_win", 
> "major_win" or whatever (maybe a better naming system is needed but whatever 
> I'll make something up). Then there will be a dashboard with the different 
> issues broken out. The Wiki is mostly to have a place where we can add 
> verbiage around the different performance ideas, why they matter, and what 
> the idea is for improving them, etc.
> 
> The next step is to have somebody prototype writing some FX micro benchmarks 
> using JMH. We're going to create a project inside rt to house these 
> benchmarks when they're written. There are multiple ways contributions can 
> happen here. You can write a micro benchmark that we can include in the 
> project so everybody can run it. This will give us the ability to measure 
> something, and "that which is measured improves". Another way to contribute 
> is to take some issue and chase it down to completion, with a patch and 
> everything. Another way is to take micro benchmarks provided by somebody else 
> and run them on your configuration and report back results.
> 
> If any of the issues in that query are particularly interesting to you, then 
> let us know you're looking at it and dive in! Start a new thread for the 
> particular issue (or better discuss it in the JIRA itself).
> 
> Cheers
> Richard

hg: openjfx/8/graphics/rt: Gradle: fix native font build

[hang . vo]

Changeset: c48aba5f8936
Author:kcr
Date:  2013-05-30 07:00 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c48aba5f8936

Gradle: fix native font build

! gradleBuildSrc/win.gradle

Re: hg: openjfx/8/graphics/rt: Replaced lambdas in FilteredList and TransformationList with anonymous classes.

[Richard Bair]

A little love for you JDK 7 back-porters :-)


On May 29, 2013, at 11:34 PM, hang...@oracle.com wrote:

> Changeset: c200cd542665
> Author:Martin Sladecek 
> Date:  2013-05-30 08:19 +0200
> URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c200cd542665
> 
> Replaced lambdas in FilteredList and TransformationList with anonymous 
> classes.
> 
> ! javafx-beans/src/javafx/collections/transformation/FilteredList.java
> ! javafx-beans/src/javafx/collections/transformation/TransformationList.java
> 

hg: openjfx/8/graphics/rt: 2 new changesets

[hang . vo]

Changeset: f2583a30a508
Author:Martin Sladecek 
Date:  2013-05-30 15:42 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f2583a30a508

Fixed infinte loop in HBox.

! javafx-ui-common/src/javafx/scene/layout/HBox.java

Changeset: 804a55322e91
Author:Martin Sladecek 
Date:  2013-05-30 15:43 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/804a55322e91

Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt

Re: [API Review] RT-15314

[Kevin Rushforth]

That's my preference as well.

-- Kevin


Tom Schindl wrote:

I'd go for option 3 at this

Tom

Von meinem iPhone gesendet

Am 29.05.2013 um 23:51 schrieb David Hill :

  

We have a request  to allow non-sandboxed 
applications to disable the "ESC to exit full screen" overly (and the associated ESC 
action to exit Full Screen).

This is needed for "kiosk" style applications where Full Screen should only be 
under programmatic control.

I have several options to present, but all of them have an underlying change, 
which is the addition of a system property to disable the overlay behavior:
   -Djavafx.fullScreenWarning=false

API Option One: Add to Platform, providing for a system toggle that is static.
 public static void setFullScreenWarning(boolean warn)
 public static boolean getFullScreenWarning()

Note: I considered other options, like Application, but felt they were poor 
fits. I am willing to listen to reason though.

API Option Two: Add to Stage. This would be a per instance change, and not a 
global toggle:
 public void setFullScreenWarning(boolean warn)
 public boolean getFullScreenWarning()

API Option Three: don't change the API at this point, rely only on the system 
properly to disable the overlay.

Note: option three seems to be a reasonable solution for many of the users of this 
functionality, because in a "kiosk" style application you can control the 
launching anyway.

--
David Hill 
Java Embedded Development

"In the business world, the rearview mirror is always clearer than the 
windshield."
-- Warren Buffett (1930 - )

Re: JavaFX graphics performance and suitability for advanced animations

[Hervé Girod]

Hmm, there's no point to talk politics about platforms here I think. 

And I don't think that we will go anywhere if we only say that Oracle does not 
do enough, or that the performance is not enough, without being more specific.

Again we use swing (yes swing...) for complex graphic cockpit soft real time 
simulations with a lot of animated elements (including purely graphic widgets), 
and we found the performance really sufficient for our use. But we heard that 
swing was not adapted for this type of use cases...

We think that we will have a better performance with JavaFX, even with 2.2. 

I'm sure that a lot of things can and must be improved for JavaFX apps 
performance, but saying that in its current state it's unusable is a bit over 
stretched.

Concerning other frameworks, I know a bit about QML, but its performance is IMO 
far below JavaFX in its current state, but regardless it seems to be used a 
lot, even with its shortcomings.

Herve

Sent from my iPhone

On 30 mai 2013, at 14:56, "John C. Turnbull"  wrote:

> Hi Richard,
> 
> Thanks for the comprehensive reply.  Responses inline.
> 
>>> 1.   Can someone from Oracle please outline the full range of
>>> applications for which JavaFX is or will be suitable for?
>> 
>> That's a pretty broad question. Lots of stuff? At a minimum everything
> Swing and SWT were used for, as well as mobile and > embedded UIs, rich
> media, graphics, etc. I don't expect somebody to write Halo 5 with it.
> 
> OK, I get that JavaFX can be used to "replace" Swing in many circumstances
> but to say "JavaFX is suitable for mobile" is a bit of a stretch considering
> Oracle's attitude to investing in developing an official release of JavaFX
> for mobile platforms.  Recent work with RoboVM has indeed shown that there
> is potential in this area but if Oracle management (and I stress
> *management*, not the JavaFX development team) still doesn't get the
> significance of tablets and mobiles and having JavaFX support on those
> devices then I don't really see JavaFX as being suitable for serious
> application development on those platforms.
> 
> Rich media?  Yes, in principle but the range of supported media formats is
> very limited.  As is the range of platforms supported by JavaFX as a whole.
> 
> Graphics?  Yes, to a point.  But my post was really about graphics and the
> issues related to performance.  Again, unless those issues are resolved then
> it's not appropriate to state that JavaFX is suitable for "graphics".  Being
> able to render simple vector graphics is nowhere near enough to encourage
> developers to adopt JavaFX for "graphics" applications.
> 
> Then you mention Halo 5.  I have to say the subtext here troubles me
> greatly.  If I read you correctly then you are saying that JavaFX is not
> really suitable for games (at least anything beyond the demands of something
> like Solitaire).  As someone else pointed out, what is point of developing
> 3D support in JavaFX if it is not really suitable for games?  To say it is
> not suitable for games implies that it is not really suitable for *any*
> application that requires performant animations and visualisations.  What
> use then is the 3D API?
> 
>>> 2.   Is there something inherent in the JavaFX architecture (such as
>>> CPU/GPU interaction, the performance of the JVM or the Java language 
>>> itself) that limits its suitability and thus effectiveness in advanced 
>>> animations/visualisations?
>> 
>> Absolutely not, in fact, quite the opposite. The basic architecture
> (threading model, GPU usage model, etc) is designed for high
>> concurrency and throughput. Some of the features in Controls though (like
> CSS lookup, color derivation, etc) put a tax on
>> performance. When it wasn't exposed in the API, every design decision is
> made with performance as a for most thought.
>> When it comes to API usability is considered primarily but performance is
> also always considered (along with security).
>> And for every feature that adds weight, there is a way to avoid it when
> absolutely necessary.
> 
> What you say here about the focus of the development work is encouraging but
> (obviously) it needs to translate to actual results in the field.
> 
>>> 3.   Is this choppiness and lack of smoothness I have experienced
>>> typical of JavaFX performance or is it some issue with my 
>>> environment/drivers etc.?
>> 
>> Hard to say. I saw a couple weeks ago a machine where scrolling the table
> view was 14fps whereas it was 320fps for me.
>> The difference was the other system was falling back to the software
> pipeline. To determine what you're seeing,
>> we need to know whether what you're running is producing consistently slow
> results or erratic results.
>> Also, we need to know whether you are render bound or compute bound.
> What's taking so long to complete?
>> 
>> We have seen situations where we are preparing a frame but never rendering
> it, which might also be contributing to the choppiness.
> 
>

RE: JavaFX graphics performance and suitability for advanced animations

[John C. Turnbull]

Hi Richard,

Thanks for the comprehensive reply.  Responses inline.

>> 1.   Can someone from Oracle please outline the full range of
>> applications for which JavaFX is or will be suitable for?
>
> That's a pretty broad question. Lots of stuff? At a minimum everything
Swing and SWT were used for, as well as mobile and > embedded UIs, rich
media, graphics, etc. I don't expect somebody to write Halo 5 with it.

OK, I get that JavaFX can be used to "replace" Swing in many circumstances
but to say "JavaFX is suitable for mobile" is a bit of a stretch considering
Oracle's attitude to investing in developing an official release of JavaFX
for mobile platforms.  Recent work with RoboVM has indeed shown that there
is potential in this area but if Oracle management (and I stress
*management*, not the JavaFX development team) still doesn't get the
significance of tablets and mobiles and having JavaFX support on those
devices then I don't really see JavaFX as being suitable for serious
application development on those platforms.

Rich media?  Yes, in principle but the range of supported media formats is
very limited.  As is the range of platforms supported by JavaFX as a whole.

Graphics?  Yes, to a point.  But my post was really about graphics and the
issues related to performance.  Again, unless those issues are resolved then
it's not appropriate to state that JavaFX is suitable for "graphics".  Being
able to render simple vector graphics is nowhere near enough to encourage
developers to adopt JavaFX for "graphics" applications.

Then you mention Halo 5.  I have to say the subtext here troubles me
greatly.  If I read you correctly then you are saying that JavaFX is not
really suitable for games (at least anything beyond the demands of something
like Solitaire).  As someone else pointed out, what is point of developing
3D support in JavaFX if it is not really suitable for games?  To say it is
not suitable for games implies that it is not really suitable for *any*
application that requires performant animations and visualisations.  What
use then is the 3D API?

>> 2.   Is there something inherent in the JavaFX architecture (such as
>> CPU/GPU interaction, the performance of the JVM or the Java language 
>> itself) that limits its suitability and thus effectiveness in advanced 
>> animations/visualisations?
>
> Absolutely not, in fact, quite the opposite. The basic architecture
(threading model, GPU usage model, etc) is designed for high
> concurrency and throughput. Some of the features in Controls though (like
CSS lookup, color derivation, etc) put a tax on
> performance. When it wasn't exposed in the API, every design decision is
made with performance as a for most thought.
> When it comes to API usability is considered primarily but performance is
also always considered (along with security).
> And for every feature that adds weight, there is a way to avoid it when
absolutely necessary.

What you say here about the focus of the development work is encouraging but
(obviously) it needs to translate to actual results in the field.

>> 3.   Is this choppiness and lack of smoothness I have experienced
>> typical of JavaFX performance or is it some issue with my 
>> environment/drivers etc.?
>
> Hard to say. I saw a couple weeks ago a machine where scrolling the table
view was 14fps whereas it was 320fps for me.
> The difference was the other system was falling back to the software
pipeline. To determine what you're seeing,
> we need to know whether what you're running is producing consistently slow
results or erratic results.
> Also, we need to know whether you are render bound or compute bound.
What's taking so long to complete?
>
> We have seen situations where we are preparing a frame but never rendering
it, which might also be contributing to the choppiness.

The symptoms I have observed are certainly not consistent in that the degree
of choppiness varies considerably from "noticeable but only mildly
distracting" to "this app is broken".

I have tried JavaFX on only 3 machines which were all Windows 7 machines but
had very different specs and GPUs.  On all those machines I observed
choppiness in all of the animations/transitions demos in Ensemble and in
every application or sample code I have ever downloaded and run for myself.
I am yet to see any JavaFX application which uses animations that has
performed in what I would describe as an acceptable manner.

What I find most interesting is that there is this significant variance in
the degree of choppiness.  On the main machine I work on (which has a very
advanced and modern GPU), the degree of choppiness varies markedly very
often.  One minute when I run an application I observe the choppiness in the
lower range and then, a minute later and with apparently no change in the
either the environment, configuration or in the apps running at the time,
the choppiness in same JavaFX application can degrade so badly that it is
severely broken.  Importantly, this 

hg: openjfx/8/graphics/rt: RT-30802: Quantum Cleanup: Make pipeline initialization happen in run()

[hang . vo]

Changeset: b29ce522d568
Author:snorthov
Date:  2013-05-30 07:39 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b29ce522d568

RT-30802: Quantum Cleanup: Make pipeline initialization happen in run()

! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/EmbeddedPainter.java

hg: openjfx/8/graphics/rt: iOS: Native library loading fixed for iOS. Adding missing JNI_OnLoad_*() functions, etc.

[hang . vo]

Changeset: 0da32bf95d30
Author:Oldrich Maticka 
Date:  2013-05-30 11:56 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0da32bf95d30

iOS: Native library loading fixed for iOS. Adding  missing JNI_OnLoad_*() 
functions, etc.
Reviewed by David Pulkrabek.

! glass/glass-lib-ios/src/GlassApplication.m
! glass/glass/src/com/sun/glass/utils/NativeLibLoader.java
! javafx-iio-native/src/ios/com_sun_javafx_iio_ios_IosImageLoader.m
! javafx-iio-native/src/jpegloader.c
! prism-common-native/src/Helpers.c
! prism-es2-native/src/ios/IOSGLFactory.c

hg: openjfx/8/graphics/rt: Method marked public by accident removed form public API

[hang . vo]

Changeset: 55c9c3a55f58
Author:Eva Krejcirova 
Date:  2013-05-30 10:35 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/55c9c3a55f58

Method marked public by accident removed form public API

! javafx-ui-common/src/javafx/scene/shape/Arc.java

Using RoboVM+JavaFX8+Bro to develop apps for iOS and Android? - Google Groups

[Tobi]

https://groups.google.com/forum/m/?fromgroups#!topic/robovm/Iii-ARUp3W0


Von meinem iPhone gesendet

hg: openjfx/8/graphics/rt: 2 new changesets

[hang . vo]

Changeset: a99a0da62147
Author:Pavel Safrata
Date:  2013-05-30 08:26 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a99a0da62147

[DOC-ONLY]: added the second asterisk for the comments to become visible for 
Javadoc.

! javafx-ui-common/src/javafx/application/ConditionalFeature.java

Changeset: 32f8e83c9e92
Author:Pavel Safrata
Date:  2013-05-30 08:29 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/32f8e83c9e92

[DOC-ONLY]: added missing comment.

! javafx-ui-common/src/javafx/scene/input/MouseEvent.java