RE: Innovation again (was Re: Text classes)

[Markus KARG]

I understand your situation very well, as it is the same for me. What would be 
great would be some mentor at the OpenJFX team who helps to get external 
contributors at speed. Not only he could decide what needs a JEP or review it 
before filing, he also could help with coding standards, tooling and building, 
and so on. I think every open source project the size of OpenJDK should have 
such mentors. Unfortunately, least do.

-Markus

 

From: John-Val Rose [mailto:johnvalr...@gmail.com] 
Sent: Mittwoch, 6. Dezember 2017 09:41
To: Markus KARG
Cc: openjfx-dev@openjdk.java.net Mailing
Subject: Re: Innovation again (was Re: Text classes)

 

Yes, I obviously need to know if anything I work on or design is going to be 
accepted or is even wanted by the community as a whole, and as early on in the 
process as possible.  Heck, if I had my way, JavaFX would be used to build 
everything from forms to FPS games and highly complex and performant 3D 
visualizations.  And don't say it can't be done in Java - it can.  
JavaMonkeyEngine can be used to create awesome games (for example).

 

Plus, I have never "done" a JEP but I believe it's quite a long and involved 
process (?)

 

So, I would appreciate some clarification on the best process and steps to take 
to go from ideas to released features.




​​

Graciously,

 

John-Val Rose

Chief Scientist/Architect

Rosethorn Technology

 

On 6 December 2017 at 19:33, Markus KARG <mar...@headcrashing.eu> wrote:

Yes, but not everything needs a JEP always. Maybe what Phil has in mind is 
small enough to be accepted without. Somebody has to decide before filing the 
JEP.

-Markus



From: Mario Torre [mailto:neugens.limasoftw...@gmail.com]
Sent: Mittwoch, 6. Dezember 2017 09:11
To: Markus KARG

Cc: openjfx-dev@openjdk.java.net
Subject: Re: Innovation again (was Re: Text classes)



I think Phil said that, the way to propose such changes is to file a Jep and 
discuss it here.



Cheers,

Mario



On Wed 6. Dec 2017 at 09:07, Markus KARG <mar...@headcrashing.eu> wrote:

I think what John actually asked for is whom to send his design upfront at the 
JFX team to get an initial judgement whether it is worth programming it, or 
whether it bears such flaws that it makes not much sense to invest any more 
time. Whether or not that decision is done by an Oracle employee or not, he 
simply needs to know whom to sent his proposal for early review.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Philip Race
Sent: Mittwoch, 6. Dezember 2017 06:50
To: John-Val Rose
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Innovation again (was Re: Text classes)

There needs to be a viable community that is not just Oracle to support you 
here ..
I think everyone has come to be dependent on Oracle to "be there".
But if there is a specific community need that Oracle doesn't see as essential, 
then the community should help out.

-phil.

On 12/5/17, 9:27 PM, John-Val Rose wrote:
> Well, that’s all fine but you didn’t address the issue of working with 
> someone within Oracle to get these innovations done.
>
> Sure, I could just toil away by myself but clearly it would be better all 
> around if there was someone with much more extensive knowledge of JavaFX and 
> its internals who was accessible when required.
>
> I would assume that a member of the Oracle JavaFX team would be such a 
> person. If not, then who?
>
>> On 6 Dec 2017, at 15:53, Philip Race<philip.r...@oracle.com>  wrote:
>>
>> I think looking at it as an Oracle-owned and controlled project maybe the 
>> first mistake here.
>> Yes it was closed source and then Oracle controlled, but not any more, OCA 
>> requirements aside.
>> It is not even a "java specification". It can be evolved at an API level 
>> without a JSR.
>> The JEP process is the main thing to be followed, although we also use CSRs 
>> too to track API.
>> Consider it that anyone who is a contributor owns (not the right word ?) a 
>> piece of it too.
>> So standing on the project is what matters. Not the company who pays you to 
>> work on it.
>>
>> -phil.
>>
>>> On 12/5/17, 8:21 PM, John-Val Rose wrote:
>>> Phil et. al.,
>>>
>>> Whilst I’m not going to be quite as “passionate” as some on this issue 
>>> (although I do understand the frustration), I would like to point out again 
>>> that this is indeed a huge gap and it is critical that it is filled ASAP.
>>>
>>> Obviously a solution where every word in a text document is a Node would be 
>>> unworkable so it would need to be architected from the ground up.
>>>
>>> I would be happy to work on such as feature, just as I was happy to work on 
>>> implementing WebGL, but my 

RE: Innovation again (was Re: Text classes)

[Markus KARG]

Yes, but not everything needs a JEP always. Maybe what Phil has in mind is 
small enough to be accepted without. Somebody has to decide before filing the 
JEP.

-Markus

 

From: Mario Torre [mailto:neugens.limasoftw...@gmail.com] 
Sent: Mittwoch, 6. Dezember 2017 09:11
To: Markus KARG
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Innovation again (was Re: Text classes)

 

I think Phil said that, the way to propose such changes is to file a Jep and 
discuss it here.

 

Cheers,

Mario 

 

On Wed 6. Dec 2017 at 09:07, Markus KARG <mar...@headcrashing.eu> wrote:

I think what John actually asked for is whom to send his design upfront at the 
JFX team to get an initial judgement whether it is worth programming it, or 
whether it bears such flaws that it makes not much sense to invest any more 
time. Whether or not that decision is done by an Oracle employee or not, he 
simply needs to know whom to sent his proposal for early review.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Philip Race
Sent: Mittwoch, 6. Dezember 2017 06:50
To: John-Val Rose
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Innovation again (was Re: Text classes)

There needs to be a viable community that is not just Oracle to support you 
here ..
I think everyone has come to be dependent on Oracle to "be there".
But if there is a specific community need that Oracle doesn't see as essential, 
then the community should help out.

-phil.

On 12/5/17, 9:27 PM, John-Val Rose wrote:
> Well, that’s all fine but you didn’t address the issue of working with 
> someone within Oracle to get these innovations done.
>
> Sure, I could just toil away by myself but clearly it would be better all 
> around if there was someone with much more extensive knowledge of JavaFX and 
> its internals who was accessible when required.
>
> I would assume that a member of the Oracle JavaFX team would be such a 
> person. If not, then who?
>
>> On 6 Dec 2017, at 15:53, Philip Race<philip.r...@oracle.com>  wrote:
>>
>> I think looking at it as an Oracle-owned and controlled project maybe the 
>> first mistake here.
>> Yes it was closed source and then Oracle controlled, but not any more, OCA 
>> requirements aside.
>> It is not even a "java specification". It can be evolved at an API level 
>> without a JSR.
>> The JEP process is the main thing to be followed, although we also use CSRs 
>> too to track API.
>> Consider it that anyone who is a contributor owns (not the right word ?) a 
>> piece of it too.
>> So standing on the project is what matters. Not the company who pays you to 
>> work on it.
>>
>> -phil.
>>
>>> On 12/5/17, 8:21 PM, John-Val Rose wrote:
>>> Phil et. al.,
>>>
>>> Whilst I’m not going to be quite as “passionate” as some on this issue 
>>> (although I do understand the frustration), I would like to point out again 
>>> that this is indeed a huge gap and it is critical that it is filled ASAP.
>>>
>>> Obviously a solution where every word in a text document is a Node would be 
>>> unworkable so it would need to be architected from the ground up.
>>>
>>> I would be happy to work on such as feature, just as I was happy to work on 
>>> implementing WebGL, but my hesitation is concern over the assistance and 
>>> involvement from Oracle.
>>>
>>> If I am going to have to spend months working on something without any or 
>>> only minimal involvement from Oracle, only to find at the end that Oracle 
>>> either doesn’t like the design, implementation or something else then it is 
>>> wasted time I’ll never get back.
>>>
>>> There are lots of other innovations too that I would like to see in JavaFX 
>>> but I just don’t “feel the enthusiasm” from Oracle.
>>>
>>> If there is someone on the JavaFX team who would be willing to work with me 
>>> (at least in some capacity), please have them contact me privately via 
>>> email.
>>>
>>> The innovations I could work on and contribute include:
>>>
>>> 1. WebGL support in WebView
>>> 2. Better text support including text documents&   rich text editors etc.
>>> 3. Significant improvements in scene graph rendering speed using
>>> modern game-engine style structures and algorithms
>>>
>>> JavaFX cannot survive without innovation and I am keen to see it happen and 
>>> contribute as much as possible.
>>>
>>> Graciously,
>>>
>>> John-Val Rose
>>> Rosethorn Technology
>>>
>>>> On 6 Dec 2017, at 11:36, jav...@use.start

RE: Innovation again (was Re: Text classes)

[Markus KARG]

I think what John actually asked for is whom to send his design upfront at the 
JFX team to get an initial judgement whether it is worth programming it, or 
whether it bears such flaws that it makes not much sense to invest any more 
time. Whether or not that decision is done by an Oracle employee or not, he 
simply needs to know whom to sent his proposal for early review.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Philip Race
Sent: Mittwoch, 6. Dezember 2017 06:50
To: John-Val Rose
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Innovation again (was Re: Text classes)

There needs to be a viable community that is not just Oracle to support you 
here ..
I think everyone has come to be dependent on Oracle to "be there".
But if there is a specific community need that Oracle doesn't see as essential, 
then the community should help out.

-phil.

On 12/5/17, 9:27 PM, John-Val Rose wrote:
> Well, that’s all fine but you didn’t address the issue of working with 
> someone within Oracle to get these innovations done.
>
> Sure, I could just toil away by myself but clearly it would be better all 
> around if there was someone with much more extensive knowledge of JavaFX and 
> its internals who was accessible when required.
>
> I would assume that a member of the Oracle JavaFX team would be such a 
> person. If not, then who?
>
>> On 6 Dec 2017, at 15:53, Philip Race  wrote:
>>
>> I think looking at it as an Oracle-owned and controlled project maybe the 
>> first mistake here.
>> Yes it was closed source and then Oracle controlled, but not any more, OCA 
>> requirements aside.
>> It is not even a "java specification". It can be evolved at an API level 
>> without a JSR.
>> The JEP process is the main thing to be followed, although we also use CSRs 
>> too to track API.
>> Consider it that anyone who is a contributor owns (not the right word ?) a 
>> piece of it too.
>> So standing on the project is what matters. Not the company who pays you to 
>> work on it.
>>
>> -phil.
>>
>>> On 12/5/17, 8:21 PM, John-Val Rose wrote:
>>> Phil et. al.,
>>>
>>> Whilst I’m not going to be quite as “passionate” as some on this issue 
>>> (although I do understand the frustration), I would like to point out again 
>>> that this is indeed a huge gap and it is critical that it is filled ASAP.
>>>
>>> Obviously a solution where every word in a text document is a Node would be 
>>> unworkable so it would need to be architected from the ground up.
>>>
>>> I would be happy to work on such as feature, just as I was happy to work on 
>>> implementing WebGL, but my hesitation is concern over the assistance and 
>>> involvement from Oracle.
>>>
>>> If I am going to have to spend months working on something without any or 
>>> only minimal involvement from Oracle, only to find at the end that Oracle 
>>> either doesn’t like the design, implementation or something else then it is 
>>> wasted time I’ll never get back.
>>>
>>> There are lots of other innovations too that I would like to see in JavaFX 
>>> but I just don’t “feel the enthusiasm” from Oracle.
>>>
>>> If there is someone on the JavaFX team who would be willing to work with me 
>>> (at least in some capacity), please have them contact me privately via 
>>> email.
>>>
>>> The innovations I could work on and contribute include:
>>>
>>> 1. WebGL support in WebView
>>> 2. Better text support including text documents&   rich text editors etc.
>>> 3. Significant improvements in scene graph rendering speed using 
>>> modern game-engine style structures and algorithms
>>>
>>> JavaFX cannot survive without innovation and I am keen to see it happen and 
>>> contribute as much as possible.
>>>
>>> Graciously,
>>>
>>> John-Val Rose
>>> Rosethorn Technology
>>>
 On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote:

 Sorry about all the typos previously.

 Question- why not use the code in awt ? I am not totally up on what's 
 going on with the platforms' native rendering engines ( meaning, I have no 
 idea whatsoever) or how they have changed, but golly it sure does still 
 work pretty well.

   At least it seems to me looking at awt that a smallish number of things 
 are 1) well defined by the native platofrm and 2) would more or less 
 translate directly to an Java API and 3) from those small number of 
 building blocks, (Font and Glyph metrics and this kind of thing)   text 
 line layout algorithms can be written by ordinary civilians along with all 
 the other stuff that goes into a text editor.

 And yes, everything does look easy when someone else is going to do it.

[8u121] Review request for JDK-8177077: Constructing multiple Image objects using animated GIFs concurrently can fail with AIOOBE

[Markus KARG]

https://bugs.openjdk.java.net/browse/JDK-8177077

 

Please review the patch attached to JDK-8177077

 

I simply wrapped invocations to Timeline.play() and Timeline.stop() by
Platform.runLater, so it should be thread safe now.

Subject: [8u121] Review request for JDK-8178837: Potential performance drawback due to type mismatch

[Markus KARG]

https://bugs.openjdk.java.net/browse/JDK-8178837

 

There is a potential performance drawback due to a type mismatch in
TriangleMesh.java:548 as `points.size()` returns `int` so storing as
`double` makes not much sense. 

 

I provided a patch which simply replaces double by int.

RE: AnimationTimer and actual frame rate

[Markus KARG]

Merry Christmas,

my personal observation when performaning an EU-fundet power consumption study 
was that once an (even no-op implementation!) AnimationTimer was registered, 
the CPU load increased by several percent _permanently_ on our lab machine. In 
contrast, with key frame animation, the CPU load stayed at zero percent but 
showed scattered peaks. Unfortunately I cannot tell you the actual 
JavaFX-internal reason for sure, but I assume that AnimationTimer is called at 
maximum possible CPU speed (i. e. more or less an endless loop) while the 
animation classes update only once per _pulse_ (i e. more or less 60 FPS).

It feels like (but this might be a false detection of mine; I did not check the 
source code) as the pure _registering_ of an AnimationTimer would enable JavaFX 
to actually run some JavaFX-internal code "undelayed", while _just_ using 
animation classes do not run that same code before the next _pulse_ (possible 
by using timer interrupts set to the next 1/60s).

It would be great if the JavaFX team could confirm this difference between 
AnimationTimer and animation classes?

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Michael Paus
Sent: Samstag, 24. Dezember 2016 10:21
To: openjfx-dev@openjdk.java.net
Subject: Re: AnimationTimer and actual frame rate

Many thanks again.

Am 23.12.16 um 18:18 schrieb Markus KARG:
> I assume it is OK for you to use internal APIs?
Of course it is :-)
>   Then you could go with:
>
> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene)
>
> and let a timer fire one per second to request tracker.getAverageFPS().
I'll give that a try as soon as my family lets me.
>
> Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if 
> the handler method is short.
Is the AnimationTimer handler more critical in this respect than any of the 
built-in animations?
>
> -Markus
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
> Behalf Of Michael Paus
> Sent: Freitag, 23. Dezember 2016 17:04
> To: openjfx-dev@openjdk.java.net
> Subject: Re: AnimationTimer and actual frame rate
>
> Thank you. That explains a lot of what I am observing but it also makes me 
> wonder how you could effectively measure the actual frame rate because that's 
> what you are normally interested in.
> Michael
>
> Am 23.12.16 um 09:15 schrieb Markus KARG:
>> AnimationTimer is fired once per "planned" frame (i. e. running at maximum 
>> possible FPS), not per "actually rendered" frame. JavaFX contains a lot of 
>> optimizations. For example, a boolean property animated over time to switch 
>> from false to true will only imply a single modification, hence only one 
>> frame is actually rendered.
>> -Markus
>>
>> -Original Message-
>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
>> Behalf Of Michael Paus
>> Sent: Donnerstag, 22. Dezember 2016 17:29
>> To: openjfx-dev@openjdk.java.net
>> Subject: AnimationTimer and actual frame rate
>>
>> Hi all,
>>
>> for quite a while now I am observing a strange behavior when running 
>> some
>>
>> JavaFX graphics tests. The scenario is very simple. I am running some 
>> animation
>>
>> which puts some load onto the graphics engine and I am trying to 
>> measure the
>>
>> frame rate via an instance of an AnimationTimer. When I increase the 
>> load high
>>
>> enough I reach a point where the indicated frame rate is just 60FPS 
>> or even a bit
>>
>> lower but the observed frame rate on screen has already dropped to 
>> something
>>
>> like 1-2 FPS. So what I observe is that the AnimationTimer is running 
>> much faster
>>
>> than the updates of the graphics. How can that be? Does anybody have 
>> an explanation
>>
>> under which circumstances this can happen? Or is this behavior a bug which I 
>> should report?
>>
>> Just some puzzle for the boring Christmas holidays :-)
>>
>> Merry Christmas to all of you
>>
>> Michael
>>
>> PS: My system is a MacBook Pro with NVidia graphic card.
>>
>>
>

RE: AnimationTimer and actual frame rate

[Markus KARG]

I assume it is OK for you to use internal APIs? Then you could go with:

com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene)

and let a timer fire one per second to request tracker.getAverageFPS().

Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if 
the handler method is short.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Michael Paus
Sent: Freitag, 23. Dezember 2016 17:04
To: openjfx-dev@openjdk.java.net
Subject: Re: AnimationTimer and actual frame rate

Thank you. That explains a lot of what I am observing but it also makes me 
wonder how you could effectively measure the actual frame rate because that's 
what you are normally interested in.
Michael

Am 23.12.16 um 09:15 schrieb Markus KARG:
> AnimationTimer is fired once per "planned" frame (i. e. running at maximum 
> possible FPS), not per "actually rendered" frame. JavaFX contains a lot of 
> optimizations. For example, a boolean property animated over time to switch 
> from false to true will only imply a single modification, hence only one 
> frame is actually rendered.
> -Markus
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
> Behalf Of Michael Paus
> Sent: Donnerstag, 22. Dezember 2016 17:29
> To: openjfx-dev@openjdk.java.net
> Subject: AnimationTimer and actual frame rate
>
> Hi all,
>
> for quite a while now I am observing a strange behavior when running 
> some
>
> JavaFX graphics tests. The scenario is very simple. I am running some 
> animation
>
> which puts some load onto the graphics engine and I am trying to 
> measure the
>
> frame rate via an instance of an AnimationTimer. When I increase the 
> load high
>
> enough I reach a point where the indicated frame rate is just 60FPS or 
> even a bit
>
> lower but the observed frame rate on screen has already dropped to 
> something
>
> like 1-2 FPS. So what I observe is that the AnimationTimer is running 
> much faster
>
> than the updates of the graphics. How can that be? Does anybody have 
> an explanation
>
> under which circumstances this can happen? Or is this behavior a bug which I 
> should report?
>
> Just some puzzle for the boring Christmas holidays :-)
>
> Merry Christmas to all of you
>
> Michael
>
> PS: My system is a MacBook Pro with NVidia graphic card.
>
>

RE: AnimationTimer and actual frame rate

[Markus KARG]

AnimationTimer is fired once per "planned" frame (i. e. running at maximum 
possible FPS), not per "actually rendered" frame. JavaFX contains a lot of 
optimizations. For example, a boolean property animated over time to switch 
from false to true will only imply a single modification, hence only one frame 
is actually rendered.
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Michael Paus
Sent: Donnerstag, 22. Dezember 2016 17:29
To: openjfx-dev@openjdk.java.net
Subject: AnimationTimer and actual frame rate

Hi all,

for quite a while now I am observing a strange behavior when running some

JavaFX graphics tests. The scenario is very simple. I am running some animation

which puts some load onto the graphics engine and I am trying to measure the

frame rate via an instance of an AnimationTimer. When I increase the load high

enough I reach a point where the indicated frame rate is just 60FPS or even a 
bit

lower but the observed frame rate on screen has already dropped to something

like 1-2 FPS. So what I observe is that the AnimationTimer is running much 
faster

than the updates of the graphics. How can that be? Does anybody have an 
explanation

under which circumstances this can happen? Or is this behavior a bug which I 
should report?

Just some puzzle for the boring Christmas holidays :-)

Merry Christmas to all of you

Michael

PS: My system is a MacBook Pro with NVidia graphic card.

RE: Planning for JavaFX.next

[Markus KARG]

+1 for CSS performance

Also I would sing and dance if some fine day the following *smaller* features 
would finally make using FXML really fun:
* Complete FXML binding syntax (JDK-8088368 [Support for Hash-Operator], 
JDK-8132450 [Custom Conversions in FXML],  JDK-8137089) 
* More bindings (JDK-8134676, JDK-8134679, JDK-8132254) 

Regards
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Jonathan Giles
Sent: Donnerstag, 8. Dezember 2016 00:45
To: openjfx-dev@openjdk.java.net
Subject: Planning for JavaFX.next

Hi folks,

Development on JDK 9 is slowly starting to ramp down, and we are starting to 
turn our attention to the goals for JavaFX in JDK 10 and beyond. We are 
starting to compile our list of what we think is important, but we really want 
to hear from the community about what their highest priorities are to them. As 
always, it's important to keep in mind what JavaFX is (e.g. it isn't aiming to 
be a high-performance game engine), but even still there are bound to be a 
number of places where people might want to weigh in, for example:

  * New layout containers (e.g. Flexbox)
  * Public APIs for UI control behaviors
  * Marlin renderer enabled by default
  * Support for CSS animations
  * CSS performance improvements
  * TableView improvements (cell spanning, row / column freezing, etc)
  * TableView performance
  * Focus traversal API
  * WebGL support in WebView
  * Improved image I/O support
  * A JavaFX equivalent of the AWT Desktop APIs
  * Multi-res image API
  * NIO-backed writable images

If there are other areas of interest that aren't listed here, please start 
discussing them and we can work together to determine priorities. 
If all you want to do is add a +1 for one of more of the items above, even that 
will be very useful.

Thanks,
-- Jonathan

RE: Fwd: Re: Marlin-Renderer and JavaFX

[Markus KARG]

Michael, note that Marlin FX still is fully software rendering, while you asked 
for more hardware rendering recently. The latter will be an additional approach 
not targeted yet by Marlin FX.
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Michael Paus
Sent: Mittwoch, 19. Oktober 2016 15:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX

I'd appreciate such a solution too.

Michael

Am 19.10.16 um 14:34 schrieb Kevin Rushforth:
> Jim Graham suggested the same thing to me privately, so he and Laurent 
> are currently looking into that possibility.
>
> -- Kevin
>
>
> Davide Malpassini wrote:
>> I think that Marlin-Renderer can be included not as a default 
>> renderer to limit the impact to the jdk9 release , but leave to the 
>> user / developer the possibility to use and test on real applications 
>> the benefit of this Renderer .
>>
>> This is only an user opinion , but i think that the benefits are big.
>> Davide Malpassini

RE: Fwd: Re: Marlin-Renderer and JavaFX

[Markus KARG]

Laurent, the problem is that OpenJDK 9's feature set is already fixed, so I 
think it is not possible to *officially* adopt huge features like Marlin FX at 
such a "late" point. Besides that I think that Marlin FX is of so high value to 
OpenJDK that I would like to nominate you as an OpenJDK committer. But that is 
up to Kevin to decide, certainly!

I don't know the internal structure of that part of JavaFX, but maybe Kevin 
could point us to some private APIs or config options one could use to allow 
anybody to simply bundle Marlin FX as an alternativ renderer with any JavaFX 8 
or 9 application?

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Laurent Bourgès
Sent: Samstag, 15. Oktober 2016 19:32
To: Kevin Rushforth
Cc: Jim Graham; openjfx-dev@openjdk.java.net
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX

Hi Kevin,

> This sounds promising. I looks forward to taking it for a test drive.

Thanks for your feedback. Could you share benchmark tools ? Or at least your 
results.
I also tested marlinFX with large texts and it rocks. See
https://bugs.openjdk.java.net/browse/JDK-8090461

> Besides asking other people to help you evaluate it and test it (which
you just did), the next step would be for you to file a JEP for javafx/graphics 
as you did earlier for client-libs/java2d. It seems like something we might 
consider for JDK 10, once the JDK 10 project is open and we start scoping it.

I know that process which is very slow and time consuming: marlin JEP265 was 
submitted in july 2015, integrated in dec 2015, few improvements after but 
still unreleased as OpenJDK9 should be GA in july 2017 !!

It took me few evenings to make MarlinFX (some cleanup work remains but only 
few days of work) and I fear that jdk10 will be released in 2020 so this 
timescale is just too far for me, as all this work will be done for free and 
consume my spare time. Moreover I would hope GPU could perform the 
rasterization at that date (opencl, panama project...)

Could somebody else endorse / sponsor this new OpenJFX JEP and help to make it 
ready for jdk9 (new JEPs are still acceptable). Of course I will not vanish but 
just focus on coding + testing improvements.

Regards,
Laurent

RE: Scene graph performance

[Markus KARG]

The limiting factor is the single-thread architecture of rather all parts of 
JavaFX. The only real difference you see between machines is not correlating 
with neither number of CPU cores nor GPU cores, but only with CPU frequency, 
roughly spoken. Short term fixes will only provide little improvement, by 
optimizing the critical execution path (i. e. produce hot spot histogram using 
a profiler), for example improvement clipping, caching, etc. Huge performance 
optimizations need an architectural change within JavaFX's 
"scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel 
execution in lots of places. Typical design patterns would be parallel 
iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, 
a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a 
tiled rendering).

I am pretty sure you can add a lot more ideas to the list and produce great 
performance, scaling linearly with number of CPU cores / GPU cores, but this 
somes at a cost: Risk to introduce hard to track bugs, and needed manpower.

If somebody has at least a lot of free spare time, I am pretty sure Kevin could 
easily provide a huge set of work items in this area. :-)

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Dr. Michael Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance

Hi Felix,
I have written various tests like the ones you use in FXMark and I have 
obtained similar results. I have even tried to substitute 2D shapes by using 3D 
MeshViews in the hope that this would give better performance but the results 
were not that good. Of course all this depends on the specific test case but in 
general I see that a JavaFX application which makes heavy use of graphics 
animations is completely CPU-bounded.
The maximum performance is reached when one CPU/Core is at 100%.
The performance of your graphics hardware seems to be almost irrelevant.
I could for example run four instances of the same test with almost the same 
performance at the same time. In this case all 4 cores of my machine were at 
100%. This proves that the graphics hardware is not the limiting factor. My 
machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics 
card which is already a couple of years old and certainly not playing in the 
same league as your high-power card.
I myself have not yet found a way to really speed up the graphics performance 
and I am a little bit frustrated because of that. But it is not only the 
general graphic performance which is a problem. There are also a lot of other 
pitfalls into which you can stumble and which can bring your animations to a 
halt or even crash your system. Zooming for example is one of these issues.

I would like to have some exchange on these issues and how to best address them 
but my impression so far is that there are only very view people interested in 
that. (I hope someone can prove me wrong on this :-)

Michael

Am 20.07.16 um 04:14 schrieb Felix Bembrick:
> Having written and tested FXMark on various platforms and devices, one 
> thing has really struck me as quite "odd".
>
> I started work on FXMark as a kind of side project a while ago and, at 
> the time, my machine was powerful but not "super powerful".
>
> So when I purchased a new machine with just about the highest specs 
> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX 
> Titan X GPUs in SLI mode, I was naturally expecting to see significant 
> performance improvements when I ran FXMark on this machine.
>
> But to my surprise, and disappointment, the scene graph animations ran 
> almost NO faster whatsoever!
>
> So then I decided to try FXMark on my wife's entry-level Dell i5 PC 
> with a rudimentary (single) GPU and, guess what - almost the same 
> level of performance (i.e. FPS and smoothness etc.) was achieved on 
> this considerably less powerful machine (in terms of both CPU and GPU).
>
> So, it seems there is some kind of "performance wall" that limits the 
> rendering speed of the scene graph (and this is with full speed 
> animations enabled).
>
> What is the nature of this "wall"? Is it simply that the rendering 
> pipeline is not making efficient use of the GPU? Is too much being done on 
> the CPU?
>
> Whatever the cause, I really think it needs to be addressed.
>
> If I can't get better performance out of a machine that scores in the 
> top 0.01% of all machine in the world in the 3DMark Index than an 
> entry level PC, isn't this a MAJOR issue for JavaFX?
>
> Blessings,
>
> Felix

RE: Update on FX plans for JDK 9

[Markus KARG]

Kevin,

I did a quick survey at TeamFX and asked every member to vote. Here is the
official TeamFX opinion. I hope it is of any worth for you.

Preface: Besides the ticket IDs you asked to prioritise TeamFX thinks that
the top issue for JDK 9 should be performance, most notably of CSS
processing. If there is one thing that holds back people from adopting
JavaFX 8 for professional use cases, then it is the fact that you can
quickly produce UI freezes of several seconds due to bugs and non-optimal
CSS processing within JavaFX. If there would be a free voting upon features,
TeamFX would replace all the below points if instead we could have JDK 9
running as fast as it could (i. e. for example create and show more than
1000 TextFields in less than a second; rotate a canvas containing 1000
complex paths fluently; and so an).

Having said that, here is the summary of our survey:

JIRA Ticket Votes   Topic
JDK-8092040 34  Implement Image writers for JavaFX
JDK-8091673 30  Runtime should have a published focus traversal API
for use in custom controls
JDK-8090477 26  Customizable visibility timing for Tooltip
JDK-8090763 22  Public API for Glass's robot functionality
JDK-8089311 21  [TableCell] commit on focus lost not possible in
every case
JDK-8092098 21  [TabPane] Support for draggable tabs
JDK-8091107 16  Add java.awt.Desktop support to javafx
JDK-8144556 16  Add support to allow user specified rendering order
JDK-8145443 16  [Mac] Render directly to NSWIndow rather than via
CALayer for non-applet Stage
JDK-8145154 16  Provide public API support for PerformanceTracker
functionality
JDK-8087516 15  Conditional support in JavaFX for GTK 3 on Linux
JDK-8091517 7   Implement com.apple.eawt APIs that make sense in
JavaFX (FX equivalent for JEP 272)

Merry Christmas
-Markus (TeamFX)


-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Kevin Rushforth
Sent: Donnerstag, 24. Dezember 2015 02:27
To: openjfx-dev@openjdk.java.net
Subject: Re: Update on FX plans for JDK 9

Thanks to everyone who has commented on this. With the winter holidays 
upon us, we will respond to feedback and pick this up next year.

-- Kevin


Kevin Rushforth wrote:
> Given the recently announced JDK 9 schedule slip [1], we have taken 
> the opportunity to explore what RFE's / Features we could possibly now 
> work on for inclusion in JDK 9. We wanted to give you a pre-holiday 
> season update on what we are currently thinking.
>
> The following RFEs are in progress or planned for JDK 9:
>
>   JDK-8144585: Encapsulate JavaFX impl_* implementation methods
>   JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
>   JDK-8091308: Define fine-grained permissions for JavaFX
>   Expose Hi-DPI properties for render scale and screen scale (FX 
> equivalent task for JEP 263 JDK-8055212)
>   Multi-resolution image support (FX equivalent task for JEP 251 
> JDK-8046010)
>
> Additionally, we have started to look into making public API for some 
> of the impl_* API that will otherwise be hidden by JDK-8144585. See 
> Jonathan's earlier e-mail on the subject [2]. Here is what we have so 
> far:
>
>   JDK-8144628: Provide API to expose list of showing Windows
>   JDK-8144625: Expose code and char properties on KeyCode
>   JDK-8144962: Promote TableColumn reorderable property to public API
>   JDK-8144871: Add default method getStyleableNode to Styleable interface
>   JDK-8145143: Promote Image.impl_getUrl() to public API as 
> Image.getUrl()
>   JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and 
> Labeled
>
> If there are any we have missed that your application depends on, 
> please send e-mail to Jonathan.
>
> Finally, here is an updated list of other RFEs we might consider for 
> JDK 9. We will not be able to do all of these, but hope to be able to 
> do many of them. We could use the help of the OpenJFX community in 
> prioritizing this list or possibly adding something that we missed, as 
> long as the scope is small enough.
>
>   JDK-8091107: Add java.awt.Desktop support to javafx
>   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX 
> (FX equivalent for JEP 272)
>   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
>   JDK-8092040: Implement Image writers for JavaFX
>   JDK-8091673: Runtime should have a published focus traversal API for 
> use in custom controls
>   JDK-8089311: [TableCell] commit on focus lost not possible in every 
> case
>   JDK-8090477: Customizable visibility timing for Tooltip
>   JDK-8092098: [TabPane] Support for draggable tabs
>   JDK-8144556: Add support to allow user specified rendering order
>   JDK-8145443: [Mac] Render directly to NSWIndow rather than via 
> CALayer for non-applet Stage
>   JDK-8145154: Provide public API support for PerformanceTracker 
> functionality
>   JDK-8090763: Public API for 

EventFilter efficiency

[Markus KARG]

I need to react upon two distinct EventTypes. There are two possibilities:
Adding two distinct event filters, each for its own event type, or add one
event filter for a family of event types, using a switch statement in
"application space" to filter for the right event. Certainly for an
application programmer it might be more nice to have one distinct filter per
event type, but I could imagine that having one common filter might reduce
the overhead for JavaFX's event management?

 

-Markus

 

 

RE: Huge JavaFX performance drop in Debian Jessie

[Markus KARG]

Just to understand "not supported GPU" better: Is there GPU-specific code in
JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU?

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Chien Yang
Sent: Dienstag, 22. Dezember 2015 09:01
To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net
Subject: Re: Huge JavaFX performance drop in Debian Jessie

Hi Chris,

JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a
high likelihood that the drop in performance is caused by the switch from sw
pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA
3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing
JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command.

- Chien

On 12/21/2015 03:02 PM, Chris Newland wrote:
> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian 
> Wheezy to Debian Jessie and JavaFX performance has suffered a huge 
> drop :(
>
> Possibly not JavaFX related but native apps (firefox etc) all seem to 
> perform the same and glxgears runs full sync framerate and 350fps 
> unsynced.
>
> JavaFX stages open blank and can take 5 seconds to render. Trying to 
> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the 
> app for 10s+.
>
> Previously stages opened in under 1s and scrolling was instant.
>
> My DemoFX test platform (Canvas based effects) seems to run the same 
> so it only appears to be windows / stages that are affected.
>
> It's an old (2010) system but JavaFX performance has dropped from slow 
> to unusable.
>
> Will keep investigating and test on my Debian desktop once I upgrade 
> it to Jessie.
>
> Cheers,
>
> Chris
> @chriswhocodes
>
> JavaFX debug:
>
> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension 
> initializeIfAvailable
> INFO: Failed to initialize management extension
> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:264)
>   at
com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40)
>   at
>
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669)
>   at
>
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java
:695)
>   at
>
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche
rImpl.java:182)
>   at java.lang.Thread.run(Thread.java:745)
>
> Prism pipeline init order: es2 sw
> Using java-based Pisces rasterizer
> Using dirty region optimizations
> Not using texture mask for primitives
> Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO 
> mode Opting in for HiDPI pixel scaling Prism pipeline name = 
> com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 
> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so 
> from relative path
>   succeeded.
> GLFactory using com.sun.prism.es2.X11GLFactory
> (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism 
> pipeline: com.sun.prism.es2.ES2Pipeline
> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from 
> relative path Maximum supported texture size: 2048 Non power of two 
> texture support = true Maximum number of vertex attributes = 16 
> Maximum number of uniform vertex components = 16384 Maximum number of 
> uniform fragment components = 16384 Maximum number of varying 
> components = 32 Maximum number of texture units usable in a vertex 
> shader = 8 Maximum number of texture units usable in a fragment shader 
> = 8 Graphics Vendor: Intel Open Source Technology Center
> Renderer: Mesa DRI Intel(R) IGD
>  Version: 2.1 Mesa 10.3.2
>   vsync: true vpipe: true
> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so 
> from relative path Loaded 
> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.s
> o
> from relative path
> Loaded
> /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so 
> from relative path
> ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag 
> new alphas
> ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag
> ES2ResourceFactory: Prism - createStockShader:
> Texture_LinearGradient_PAD.frag
> ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag
> ES2ResourceFactory: Prism - createStockShader: 
> Solid_TextureFirstPassLCD.frag
> ES2ResourceFactory: Prism - createStockShader:
> Solid_TextureSecondPassLCD.frag
> ES2ResourceFactory: Prism - createStockShader:
> FillPgram_LinearGradient_PAD.frag
> ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag
> ES2ResourceFactory: 

RE: Huge JavaFX performance drop in Debian Jessie

[Markus KARG]

Chris,

can you please check what the JFX thread does whilst the scroll-freeze (e.
g. using jstack or jvisualvm)? It would be great to learn whether it is
related to JDK-8145565.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Chris Newland
Sent: Dienstag, 22. Dezember 2015 00:03
To: openjfx-dev@openjdk.java.net
Subject: Huge JavaFX performance drop in Debian Jessie

Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to
Debian Jessie and JavaFX performance has suffered a huge drop :(

Possibly not JavaFX related but native apps (firefox etc) all seem to
perform the same and glxgears runs full sync framerate and 350fps unsynced.

JavaFX stages open blank and can take 5 seconds to render. Trying to scroll
a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+.

Previously stages opened in under 1s and scrolling was instant.

My DemoFX test platform (Canvas based effects) seems to run the same so it
only appears to be windows / stages that are affected.

It's an old (2010) system but JavaFX performance has dropped from slow to
unusable.

Will keep investigating and test on my Debian desktop once I upgrade it to
Jessie.

Cheers,

Chris
@chriswhocodes

JavaFX debug:

Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension
initializeIfAvailable
INFO: Failed to initialize management extension
java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40)
at
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669)
at
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java
:695)
at
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche
rImpl.java:182)
at java.lang.Thread.run(Thread.java:745)

Prism pipeline init order: es2 sw
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling Prism pipeline name =
com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from
relative path
succeeded.
GLFactory using com.sun.prism.es2.X11GLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism
pipeline: com.sun.prism.es2.ES2Pipeline
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from
relative path Maximum supported texture size: 2048 Non power of two texture
support = true Maximum number of vertex attributes = 16 Maximum number of
uniform vertex components = 16384 Maximum number of uniform fragment
components = 16384 Maximum number of varying components = 32 Maximum number
of texture units usable in a vertex shader = 8 Maximum number of texture
units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source
Technology Center
   Renderer: Mesa DRI Intel(R) IGD
Version: 2.1 Mesa 10.3.2
 vsync: true vpipe: true
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from
relative path Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so
from relative path
Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from
relative path
ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new
alphas
ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag
ES2ResourceFactory: Prism - createStockShader:
Texture_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag
ES2ResourceFactory: Prism - createStockShader:
Solid_TextureFirstPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
Solid_TextureSecondPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
FillPgram_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag
ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new
alphas new alphas
PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4

RE: Constant resetting to initial-state when adding/remove styleclasses

[Markus KARG]

+1

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Tom Schindl
Sent: Dienstag, 22. Dezember 2015 07:16
To: openjfx-dev@openjdk.java.net
Subject: Constant resetting to initial-state when adding/remove styleclasses

Hi,

While debugging some code I attached a listener to a property and
noticed that whenever a style-class is added to the control or even
worse somewhere in the parent hierarchy that FX resets the value to its
initial state (Node#reapplyCss & CssStyleHelper) only to set it back to
it's real value with the next CSS-Pass triggered by the next pulse.

I don't want to imagine if this happens with many value set via CSS and
eg adding/remove a styleclass to the scene root. Is this behavior really
by design like this?

You can try that yourself with the attached program below and using the
css at the end. I'm writing this because of Kevins request what the team
should invest time to because of Java9 delays and frankly all of those
bugs/features sound relevant and interesting but JavaFX performance
(most important CSS-Performance) is still miles away from eg browsers
who are the main competitors.

It doesn't help me to get an java.awt.Desktop replacement if my
input-forms do not render in a decent time frame - I would even say
rendering them in 2015 most be almost instant.

Tom

> package application;
> 
> import javafx.application.Application;
> import javafx.stage.Stage;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.HBox;
> import javafx.scene.layout.StackPane;
> 
> 
> public class Main extends Application {
>   @Override
>   public void start(Stage primaryStage) {
>   try {
>   BorderPane root = new BorderPane();
> 
>   StackPane p = new StackPane();
>   p.getStyleClass().add("test-css");
>   p.maxWidthProperty().addListener( (o, ol, ne) -> {
>   System.err.println("Modified : " + ol + " " + 
> ne);
>   Thread.dumpStack();
>   });
> 
>   root.setCenter(p);
> 
>   HBox box = new HBox();
> 
>   {
>   Button b = new Button("Modify Pane CSS");
>   b.setOnAction( e -> 
> p.getStyleClass().add("dummy"));
>   box.getChildren().add(b);
>   }
> 
>   {
>   Button b = new Button("Modify Root CSS");
>   b.setOnAction( e -> {
>   root.getStyleClass().add("dummy");
>   });
>   box.getChildren().add(b);
>   }
> 
>   root.setBottom(box);
> 
>   Scene scene = new Scene(root,400,400);
>   
> scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm());
>   primaryStage.setScene(scene);
>   primaryStage.show();
>   } catch(Exception e) {
>   e.printStackTrace();
>   }
>   }
> 
>   public static void main(String[] args) {
>   launch(args);
>   }
> }


> .test-css {
>   -fx-max-width: 300;
> }



-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

RE: Huge JavaFX performance drop in Debian Jessie

[Markus KARG]

Thanks for the stacktrace. This is definitively a separate issue. Yours
actually waits for the renderer to complete the previous frame. Mine is
heavily working inside ToolbarSkin. Technically unrelated, but leading to
the same outcome: frozen UI.

What seems odd is that the object reference the JavaFX thread is waiting for
is not locked by any other thread, particularly *not* the renderer. Never
saw something like that.

One more thing I noticed in your stacktrace: The prism font dispose has
locked an object and now waits for exactly that object. That looks strange.
How can a thread wait for an object which itself has locked?!

-Markus

-Original Message-
From: Chris Newland [mailto:cnewl...@chrisnewland.com] 
Sent: Dienstag, 22. Dezember 2015 10:06
To: Chien Yang; Markus KARG
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Huge JavaFX performance drop in Debian Jessie

Hi Chien,

Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX
desktop performance is still noticably worse than in Wheezy (probably
because the CPU is now doing all the work and this little Atom is maxed
out).

Something has definitely changed under the hood in Jessie but it's
probably only noticeable in these low powered GPUs. Slowdown is with
LXDE+lightdm and also Gnome3.

Markus,

Here is what the threads are doing when the scrollbar is hanging (with es2)

Regards,

Chris

2015-12-22 09:00:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode):

"Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000
nid=0x17f9 waiting on condition [0x]
   java.lang.Thread.State: RUNNABLE

"Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800
nid=0x17e1 in Object.wait() [0x7fec3a5b2000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xe10486f8> (a
java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at com.sun.javafx.font.Disposer.run(Disposer.java:93)
at java.lang.Thread.run(Thread.java:745)

"JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800
nid=0x17e0 waiting on condition [0x7fec4412e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf67d7668> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(
AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru
ptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt
ibly(AbstractQueuedSynchronizer.java:1304)
at
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol
lector.java:157)
at
com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j
ava:127)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355)
at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381)
at
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510)
at
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490)
at
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki
t.java:319)
at
com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown
Source)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java
:95)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at
com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139)
at
com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)

"Thread-2" #11 daemon prio=5 os_prio=0 tid=0x7fec4c08f800 nid=0x17df
in Object.wait() [0x7fec70143000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at
com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126)
- locked <0xe0ffc670> (a java.lang.St

RE: Huge JavaFX performance drop in Debian Jessie

[Markus KARG]

What I meant with "odd" is the fact that a thread is waiting for a lock
instance which is not told by the stack trace as locked by another thread,
and that there is a thread which is waiting for a lock obtained by itself. I
haven't seen this patterns before, but I also must confess that I am not an
expert in reading stack traces. ;-)

-Markus

 

From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] 
Sent: Dienstag, 22. Dezember 2015 16:57
To: Markus KARG
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Huge JavaFX performance drop in Debian Jessie

 

This is the normal stack trace I would expect when waiting for rendering to
complete and the rendering is taking a long time.

So in short: I see nothing strange or remarkable about the stack trace.

-- Kevin


Markus KARG wrote: 

Thanks for the stacktrace. This is definitively a separate issue. Yours
actually waits for the renderer to complete the previous frame. Mine is
heavily working inside ToolbarSkin. Technically unrelated, but leading to
the same outcome: frozen UI.
 
What seems odd is that the object reference the JavaFX thread is waiting for
is not locked by any other thread, particularly *not* the renderer. Never
saw something like that.
 
One more thing I noticed in your stacktrace: The prism font dispose has
locked an object and now waits for exactly that object. That looks strange.
How can a thread wait for an object which itself has locked?!
 
-Markus
 
-Original Message-
From: Chris Newland [mailto:cnewl...@chrisnewland.com] 
Sent: Dienstag, 22. Dezember 2015 10:06
To: Chien Yang; Markus KARG
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Huge JavaFX performance drop in Debian Jessie
 
Hi Chien,
 
Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX
desktop performance is still noticably worse than in Wheezy (probably
because the CPU is now doing all the work and this little Atom is maxed
out).
 
Something has definitely changed under the hood in Jessie but it's
probably only noticeable in these low powered GPUs. Slowdown is with
LXDE+lightdm and also Gnome3.
 
Markus,
 
Here is what the threads are doing when the scrollbar is hanging (with es2)
 
Regards,
 
Chris
 
2015-12-22 09:00:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode):
 
"Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000
nid=0x17f9 waiting on condition [0x]
   java.lang.Thread.State: RUNNABLE
 
"Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800
nid=0x17e1 in Object.wait() [0x7fec3a5b2000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xe10486f8> (a
java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at com.sun.javafx.font.Disposer.run(Disposer.java:93)
at java.lang.Thread.run(Thread.java:745)
 
"JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800
nid=0x17e0 waiting on condition [0x7fec4412e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf67d7668> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(
AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru
ptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt
ibly(AbstractQueuedSynchronizer.java:1304)
at
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol
lector.java:157)
at
com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j
ava:127)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355)
at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381)
at
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510)
at
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490)
at
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki
t.java:319)
at
com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown
Source)
  

RE: Update on FX plans for JDK 9

[Markus KARG]

Does you plan to make more APIs public the Area class? Applications which
simply want to register events like "when the mouse hovers of this area of a
picture then notify me" where 'area' is an arbitrarily shaped region of the
screen. Currently this has to be done with invisible Shapes, which 'feels'
to be the wrong way as there is an Area class inside of JavaFX. :-)

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Kevin Rushforth
Sent: Donnerstag, 17. Dezember 2015 15:22
To: openjfx-dev@openjdk.java.net
Subject: Update on FX plans for JDK 9

Given the recently announced JDK 9 schedule slip [1], we have taken the
opportunity to explore what RFE's / Features we could possibly now work on
for inclusion in JDK 9. We wanted to give you a pre-holiday season update on
what we are currently thinking.

The following RFEs are in progress or planned for JDK 9:

   JDK-8144585: Encapsulate JavaFX impl_* implementation methods
   JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
   JDK-8091308: Define fine-grained permissions for JavaFX
   Expose Hi-DPI properties for render scale and screen scale (FX equivalent
task for JEP 263 JDK-8055212)
   Multi-resolution image support (FX equivalent task for JEP 251
JDK-8046010)

Additionally, we have started to look into making public API for some of the
impl_* API that will otherwise be hidden by JDK-8144585. See Jonathan's
earlier e-mail on the subject [2]. Here is what we have so far:

   JDK-8144628: Provide API to expose list of showing Windows
   JDK-8144625: Expose code and char properties on KeyCode
   JDK-8144962: Promote TableColumn reorderable property to public API
   JDK-8144871: Add default method getStyleableNode to Styleable interface
   JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()
   JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and
Labeled

If there are any we have missed that your application depends on, please
send e-mail to Jonathan.

Finally, here is an updated list of other RFEs we might consider for JDK 9.
We will not be able to do all of these, but hope to be able to do many of
them. We could use the help of the OpenJFX community in prioritizing this
list or possibly adding something that we missed, as long as the scope is
small enough.

   JDK-8091107: Add java.awt.Desktop support to javafx
   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX
equivalent for JEP 272)
   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
   JDK-8092040: Implement Image writers for JavaFX
   JDK-8091673: Runtime should have a published focus traversal API for use
in custom controls
   JDK-8089311: [TableCell] commit on focus lost not possible in every case
   JDK-8090477: Customizable visibility timing for Tooltip
   JDK-8092098: [TabPane] Support for draggable tabs
   JDK-8144556: Add support to allow user specified rendering order
   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
for non-applet Stage
   JDK-8145154: Provide public API support for PerformanceTracker
functionality
   JDK-8090763: Public API for Glass's robot functionality

Let us know what is most important to your application.

We will keep you posted with updates on what exactly is being targeted (note
that you can track it by looking at the Fix Version in JBS, which we strive
to keep up-to-date).

Thanks!

-- Kevin

[1]
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
[2]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html

RE: Oracle's mobile JDK ports & JavaFX

[Markus KARG]

This sounds very encouraging! Are there any forecasts of a time frame when this 
will be stable enough to let us "play" with? :-)

-Markus (TeamFX)

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Johan Vos
Sent: Dienstag, 15. Dezember 2015 09:50
To: Felix Bembrick
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Oracle's mobile JDK ports & JavaFX

Hi Felix,

The Oracle Mobile JVM ports are headless so they are very complimentary to the 
work done in javafxports/Gluon.
A couple of months ago, we tested the iOS simulator (created a JDK 9 build and 
added a slightly modified javafxports version on top) with a simple JavaFX app 
and that worked nice.
Have a look at https://twitter.com/eryzhikov/status/659148074397229056 for a 
short movie on how it looks like.

In general, JavaFX just requires a JVM to run, and it doesn't matter if this is 
provided by Oracle, RoboVM or Dalvik/ART.
However, having a single codebase for the VM that runs on desktop and the VM's 
that run on mobile is a huge advantage. It is still early to tell, but I am 
very excited about this project. With this project, you can write your Java 
Client apps in Java 9 and run them on almost any device. Combine that with 
JavaFX 9 and you have a great platform for UI development. One codebase, one 
language, almost all devices. It sounds marketing talk but it is the technical 
reality.

To be honest, I don't have too high expectations for performance at this 
moment. But it is something that can be worked on. From what I've seen, there 
are some really smart people working on it. I hope there will be many 
contributions from inside and outside of Oracle to this project. So I hope it 
results in faster apps, but don't expect amazing performance gains from day 
one. Unrelated, we are still working on performance enhancements inside 
JavaFXPorts, and those are mainly native so the VM won't have a big impact on 
this.

We will add the option to select a specific JVM (RoboVM
free/commercial/OpenJDK/Android) in the jfxmobile plugin, and let developers 
decide what they want to bundle their app with.

This blog post might be interesting to you:
http://gluonhq.com/gluon-supports-multiple-jvms/

- Johan


On Tue, Dec 15, 2015 at 9:05 AM, Felix Bembrick 
wrote:

> With Oracle now officially announcing their intention to port the Java 
> 9 JDK to iOS, Android and even Windows Phone, how does this impact or 
> fit in with the current work being done through OpenJFXPorts and Gluon with 
> JavaFX?
>
> Is it something that could be used with JavaFX, complementing the 
> existing work or would it be a completely new strategy for porting 
> Java and JavaFX to mobile platforms?
>
> Could it potentially result in a faster port of JavaFX on those platforms?
>
> Thanks,
>
> Felix

RE: Future of JavaFX

[Markus KARG]

JavaFX support for multi-resolution images is really a killer feature, as it 
simply is ridiculous how small images render on HiDPI that are scaled for 
LowDPI.

For JDK 10, I'd kindly ask to review the list of essentials that I sent you 
some months back by personal mail.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Kevin Rushforth
Sent: Mittwoch, 2. Dezember 2015 01:29
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

Just to chime in on a couple of points that have been raised in this 
discussion...

* We are interested in working with the OpenJFX community to improve JavaFX. In 
particular: if you find a bug, file it (via bugs.java.com if you don't have a 
JBS account); if you want to contribute a patch to fix the bug, we'd love to 
review it; if you have an idea for an improvement, file it as an RFE 
(enhancement) and start up a thread on the mailing list. Larger features need a 
JEP, but smaller improvements do not.

Please be aware that as part of the OpenJDK community, we are bound by the 
processes of the OpenJDK, including the need for a signed OCA in order to 
contribute, and before you can get a JBS account. If you are dissatisfied with 
those processes and policies, then I invite you to discuss it on the 
disc...@openjdk.java.net alias, and not here.


* While we aren't planning a huge number of features in JDK 9, we are 
delivering some interesting improvements. Jigsaw is the big release driver and 
most of our effort on JavaFX is to align with that. For those of you who 
weren't at JavaOne, here is a list of things that are currently planned for JDK 
9:

- A modularized JavaFX (into 6 core modules + deploy, swing interop, swt
interop)

- JEP 253 -- Control Skins & additional CSS APIs (proper support for 
third-party controls)

- High DPI enhancements (full support on Windows; add support for Linux)

- Public API for commonly used methods from internal packages:
* Nested Event Loop
* Pulse Listener
* Platform Startup
* Text API (HitTest, etc)
* Static utility functions (under investigation)

- New versions of WebKit and GStreamer

And here is an incomplete list of things we are thinking about for after JDK 9, 
possibly in an update release. In fact, the recently proposed JDK
9 slip [1] makes it possible to consider pulling a few of them into JDK 9, so 
let us know which ones you consider most important:

- Provide a JavaFX equivalent for JEP 272 / AWT ‘Desktop’ API

- Make UI Control Behaviors public

- UI Control Actions API

- Public Focus Traversal API

- JavaFX support for multi-resolution images

- Draggable tabs

- Image IO


-- Kevin

[1]
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html

RE: Future of JavaFX

[Markus KARG]

Agreed.

-Original Message-
From: Phil Race [mailto:philip.r...@oracle.com] 
Sent: Donnerstag, 3. Dezember 2015 19:39
To: Markus KARG; openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

As Kevin already said, you won't get anywhere by discussing that on
*this* list.
It is out of the control of JavaFX. It is an OpenJDK-wide policy regarding the 
bug tracker.
You would need to take it to openjdk-discuss since it is common across all 
OpenJDK projects.
And there is some work in progress the submission easier and to provide means 
to add updates. I think that may have been shared in a previous thread on this 
or some other list.

-phil.

On 12/3/2015 10:31 AM, Markus KARG wrote:
> +1
>
> It simply must be possibly for *everyone* to open tickets, comment on 
> tickets, vote for tickets, without signing a CLA. We simply could have bylaws 
> that say that you agree to the CLA simply by using the tracker. In Germany 
> for example, this is possible by posting the licence agreement on the same 
> web site and the words "By using this service you agree to this terms.".
>
> The must be people in charge reviewing small contributions and directly tell 
> in the comments field what exactly is needed to be accepted as a contribution.
>
> Everything else will hold people back from contributing small contributions 
> or even report bugs.
>
> -Markus
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
> Behalf Of Mark Fortner
> Sent: Donnerstag, 3. Dezember 2015 00:12
> To: Florian Brunner
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
>
> I think the first hurdle is to get people to sign the CLA. Having to 
> print a copy, sign it, and find a fax machine or scanner to resend it 
> seems kind of archaic in this day and age.  That said, e-signing a PDF 
> shouldn't be too difficult, but it would be better if it were simply a 
> form that you attached your public key to. This would serve 2 
> purposes: (1) you have a proxy for a signature, (2) the key could be used to 
> access the repo.
>
> That said, even that might be too much for people who just have a 
> quick bug fix that they'd like to see reviewed and merged.
>
> Cheers,
>
> Mark
>
>
> On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner <fbrunnerl...@gmx.ch> wrote:
>
>> Some time ago there actaully was a OpenJFX mirror repository on BitBucket.
>>
>> I'm not totally sure anymore why this was stopped. I think it needs 
>> someone who keeps the repositories in sync and there were some 
>> concerns that it's harder to control who wrote a patch. But maybe the 
>> idea with CLA signers only members would solve this issue?
>>
>> So I see 3 pain points being raised.
>>
>> 1. Signing the CLA.
>>  - Personally, I don't see any way around this. If there is 
>> no CLA then you end up with a project _nobody_ is in control of.
>>  - Basically it envolves the following steps:
>>   -- Download it from the website
>>   -- print it
>>   -- sign it
>>   -- send it off
>>   -- you only have to do this once
>>   -- you don't have to wait for Oracle to receive it to start 
>> working on the issue you like to solve
>>
>> Can this be presented in a way it doesn't scare people away as 
>> according to some statements it seems to do now?
>>
>> 2. State-of-the-art code collaboration platform.
>>  -- This would have to be something like GitHub or BitBucket
>>  -- Only CLA signers can be members of the project
>>  -- Someone has to be in charge to synchronize the 
>> repositories (probably one way only)
>>  -- personally I like to work with feature branches in Git 
>> but I think you can get something similar with Mercurial bookmarks. 
>> So
>>  --- pick an issue you would like to work on
>>  --- consider to announce it on this mailing list
>>  --- create a feature branch
>>  --- start pushing your changes to the feature branch
>>  --- other developers of the projects (all CLA signers) might 
>> chime in as they like
>> --- once you think you're finished create a patch from the 
>> feature branch and add it to the issue or (if you don't have enough 
>> rights) send it to the mailing list
>> --- take the feedback from the review, do the fixes an create 
>> another patch etc.
>>
>> So the main benefit would be that several developers could work on 
>> the same issue until it gets to a high enough qualiy state to be 
>> merged into the main r

RE: Future of JavaFX

[Markus KARG]

+1

It simply must be possibly for *everyone* to open tickets, comment on tickets, 
vote for tickets, without signing a CLA. We simply could have bylaws that say 
that you agree to the CLA simply by using the tracker. In Germany for example, 
this is possible by posting the licence agreement on the same web site and the 
words "By using this service you agree to this terms.".

The must be people in charge reviewing small contributions and directly tell in 
the comments field what exactly is needed to be accepted as a contribution.

Everything else will hold people back from contributing small contributions or 
even report bugs.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Mark Fortner
Sent: Donnerstag, 3. Dezember 2015 00:12
To: Florian Brunner
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

I think the first hurdle is to get people to sign the CLA. Having to print
a copy, sign it, and find a fax machine or scanner to resend it seems kind
of archaic in this day and age.  That said, e-signing a PDF shouldn't be
too difficult, but it would be better if it were simply a form that you
attached your public key to. This would serve 2 purposes: (1) you have a
proxy for a signature, (2) the key could be used to access the repo.

That said, even that might be too much for people who just have a quick bug
fix that they'd like to see reviewed and merged.

Cheers,

Mark


On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner <fbrunnerl...@gmx.ch> wrote:

> Some time ago there actaully was a OpenJFX mirror repository on BitBucket.
>
> I'm not totally sure anymore why this was stopped. I think it needs someone
> who keeps the repositories in sync and there were some concerns that it's
> harder to control who wrote a patch. But maybe the idea with CLA signers
> only
> members would solve this issue?
>
> So I see 3 pain points being raised.
>
> 1. Signing the CLA.
> - Personally, I don't see any way around this. If there is no CLA
> then you
> end up with a project _nobody_ is in control of.
> - Basically it envolves the following steps:
>  -- Download it from the website
>  -- print it
>  -- sign it
>  -- send it off
>  -- you only have to do this once
>  -- you don't have to wait for Oracle to receive it to start
> working
> on the issue you like to solve
>
>Can this be presented in a way it doesn't scare people away as
> according to
> some statements it seems to do now?
>
> 2. State-of-the-art code collaboration platform.
> -- This would have to be something like GitHub or BitBucket
> -- Only CLA signers can be members of the project
> -- Someone has to be in charge to synchronize the repositories
> (probably one way only)
> -- personally I like to work with feature branches in Git but I
> think
> you can get something similar with Mercurial bookmarks. So
> --- pick an issue you would like to work on
> --- consider to announce it on this mailing list
> --- create a feature branch
> --- start pushing your changes to the feature branch
> --- other developers of the projects (all CLA signers) might chime
> in
> as they like
>--- once you think you're finished create a patch from the feature
> branch and add it to the issue or (if you don't have enough rights) send
> it to
> the mailing list
>--- take the feedback from the review, do the fixes an create
> another
> patch etc.
>
> So the main benefit would be that several developers could work on the same
> issue until it gets to a high enough qualiy state to be merged into the
> main
> repository and not requiring one developer to do it all on his/ her own.
>
>
> 3. Filing and commenting on issues
>   - if you don't have enough rights, file it on bugs.java.com
>   - ask on this mailing list (or ask someone you know on this mailing list
> to
> do it for you) about the corresponding issue on bugs.openjdk.java.net
>  - someone from Oracle should give anyone who filed an issue that made it
> to
> bugs.openjdk.java.net the enough rights so he/ she can join on the
> discussion
> in the issue
>
> Any better way?
>
>
> -Florian
>
> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula:
> > The proposed strategy also applies to bitbucket, which does have
> mercurial
> > support ;)
> >
> > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG <mar...@headcrashing.eu>
> wrote:
> > > Too bad that Github cannot fork mercurial repos. It would be
> interesting
> > > to see the real number of pull requests such a fork would gain. Maybe

RE: Future of JavaFX

[Markus KARG]

I understand all you said, but at least, let me answer to your accusations,
before we stop this thread and go back to technical discussions:

In fact you blaim the wrong person. Indeed am speaking for TeamFX (a group
of JavaFX experts) and JUG leaders, wanting to actually help Oracle; but to
do that, we need the ability to vote and comment on tickets, so we can work
together with Oracle. We also want to add small contributions made by us
(partly done and visible in JIRA already, but cannot get finished, due to
missing JIRA accounts), but we need to have a JIRA ticket for each of it as
the main communication system for the team. JIRA is essential for a team
these days. Unfortunately, OpenJDK does not provide JIRA access to *Some* of
us, so simply we cannot *efficiently* work together with Oracle as we have
to send back-and-forth the building bricks and then wait for someone from
Oracle to find the time to review it.

That's the sole point. Not asking Oracle to do the work. Exactly the
opposite! :-)

Reagrds
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
dalibor topic
Sent: Donnerstag, 3. Dezember 2015 14:35
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

On 02.12.2015 18:45, Markus KARG wrote:
> I wouldn't bother you if I wouldn't have met those people and listened to
> their ideas, BTW.

One type of ideas one can regularly see in open source communities is 
'someone else should do X', where X can range from 'change their 
workflow to suit mine', over 'add a feature or fix a bug affecting my 
customer', to 'pay other people to do what I tell them to do', for example.

While the idea of being entitled to benefiting from other people's work 
is individually attractive, in open source communities allowing too much 
of this type of free riding attitude can cause a 'tragedy of the 
commons'. [1]

When it comes to OpenJDK, the way it is set up to work (since its 
inception) to avoid that type of problems is to mostly cater to the 
needs of OpenJDK developers, rather then to the needs of users of 
downstream products.

The OpenJDK processes allow and enable contributors with sufficient 
skills, humbleness and experience to become OpenJDK developers 
themselves, getting write access to corresponding parts of OpenJDK 
infrastructure.

But contrary to what some people may think, one should not attempt to 
recruit the largest possible number of contributors just for the sake of 
attracting contributors. The best kind of open source contributors come 
with a purpose, rather than armed with ideas they want others to work on.

On the other hand, if someone is just looking for others to work on 
issues they are interested in, that's fine, too. They can, for example, 
find Oracle's Java SE Support at [0], or in other ways attempt to 
arrange for others to pursue those ideas for them, for example by filing 
an issue or RFE on bugs.java.com, or hiring someone to implement/fix it 
for them.

Whatever option one picks, please refrain from using this technical 
mailing list for non-technical discussions. [2] As a reminder, technical 
discussions are about code.

cheers,
dalibor topic

[0] 
http://www.oracle.com/us/technologies/java/standard-edition/support/overview
/index.html
[1] https://www.youtube.com/watch?v=xC3J2pdVXX0
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018320.html

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

RE: App freezing on Linux

[Markus KARG]

Please try again with JavaFX 1.8.0_66.
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Bryan Buchanan
Sent: Mittwoch, 2. Dezember 2015 09:30
To: openjfx-dev@openjdk.java.net
Subject: App freezing on Linux

I have a customer testing an FX app and more often than not, if the app is
left open for a while (20 minutes or so), either the mouse ceases to work,
or if it does work, when you click a field, or do something that should
re-paint the window, the whole FX window goes totally grey and the app
"disappears".

I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and
without these options, and it seems to make no difference.

The system is Xubuntu 14.0.43,  kernel 3.13.0-71 running on a Gigabyte
Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my
office, but have run up a system with the same OS, kernel and Java, and
cannot re-produce the problem.

Are the any other command line switches, or debug flags that I can set to
try and get a handle on why this is happening ?

(Hope this is the right list for issues like this).

RE: Future of JavaFX

[Markus KARG]

I see it differently. Often the initial contribution does not fulfil the
quality, because the original author alone has not the time to fix all the
law stuff, but just has a great idea and hacks it down. Then others chime in
an fix it. I often saw (an helped with) such features in other open source
projects like PostgreSQL, JOnAS, FOP, DITA-OT... and it was always a great
experience to work *together* to get the thing running and finally done in
the wanted quality.

This is not possible in the JavaFX project, as the original author has no
chance to file to core idea and let others finish it, since you expect the
original author not only having the great idea and hack together the first
draw, but first of all, sign papers, read lots of rules and process
definitions, and so on, before you even take a look at his idea (this is
what happened to me several times). Hence, you expect the original author to
have plenty of time to do all that on his own, all alone. That does not
match on most community driven open source authors, it only matches on
commercial open source vendors.

So actually you only want to get contributions from Oracle, IBM, Gluan and
possibly a hand full of fully paid others, but not from the user space.
That's a pity, because that user space has a lot of great ideas. So if you
only want full-time contributors, please say it loud and clear on the "how
to contribute" page, and all that "noise" from the community will stop at
once -- including USING JavaFX as a side effect.

I wouldn't bother you if I wouldn't have met those people and listened to
their ideas, BTW.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
dalibor topic
Sent: Mittwoch, 2. Dezember 2015 10:46
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

On 01.12.2015 22:58, Markus KARG wrote:
> I actually talk about those people that *did not* invest the time to
> contribute

Making high quality contributions to open source projects takes a 
considerable amount of humbleness, time and effort. People who aren't 
able or willing to invest the necessary time and effort into making high 
quality contributions are not likely to produce acceptable results - in 
any open source community.

To quote Jono Bacon:

"Low-quality contributors don't bring much other than noise: they are a 
net drain on resources because other good contributors have to take time 
away to support them." [1]

cheers,
dalibor topic

[1] http://opensource.com/life/15/3/how-to-fire-community-members
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

RE: Future of JavaFX

[Markus KARG]

We should ask ourselfs whether we want more contributions or not. We will not 
get them until we change something. Most contributors in the Open Source just 
want to drop a bug report or a feature or two, and multiplied by the number of 
those guys, this is a lot of stuff. Only few contributors are willing to stay 
for long time, and only for those it makes sense to have the complex rules. For 
example, I do not see why we cannot have a dedicated full time "Community 
Officer" who simply collects the contributions, reviews it, applies the needed 
checks and rules and all that instead of asking everybody to follow a complex 
process? That would ensure the quality, but not for the cost of losing 
contributors.

-Original Message-
From: Hervé Girod [mailto:herve.gi...@gmail.com] 
Sent: Dienstag, 1. Dezember 2015 20:19
To: Markus KARG
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

Things are not different for Apache projects. Google does not accept any 
external contributions. The Linux kernel development is very tightly 
controlled. We should stop considering that widespread open source policies are 
only a problem with JavaFX. These policies are in place for a reason.

Hervé 

Sent from my iPhone

> On Dec 1, 2015, at 20:13, Markus KARG <mar...@headcrashing.eu> wrote:
> 
> I wonder why I was able to jointly assign my copyright with a lot of other
> open source projects without having to sign papers, sent them in by fax,
> wait for a written agreement, and pray to get a JIRA account... ;-)
> 
> See, I talked to a real lot of former JavaFX contributors in the past weeks
> (visited some European JUGs in 2015), and *virtually everybody* told me that
> he is really unsatisfied with the fact that he cannot directly file to JIRA
> anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX team
> clear about how many contributors you lost by that policy? I really wonder
> whether you see the reality there outside of Oracle. People stopped
> reporting bugs! This is a real problem for JavaFX. You should act. Now.
> 
> -Markus
> 
> 
> 
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
> dalibor topic
> Sent: Dienstag, 1. Dezember 2015 19:06
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
> 
>> On 01.12.2015 18:35, Markus KARG wrote:
>> With respect to TeamFX, the better question is: Are there plans to further
>> open the project so third party has an easier channel to contribute
> without
>> the hazzle of contributor agreements
> 
> "Like many other open-source communities, the OpenJDK Community requires 
> Contributors to jointly assign their copyright on contributed code." as 
> http://openjdk.java.net/contribute/ wisely says.
> 
> There is no good reason to change that.
> 
> cheers,
> dalibor topic
> -- 
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
> 
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> 
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
> 

RE: Future of JavaFX

[Markus KARG]

Dalibor,

exactly what I expected to hear from Oracle! You count the number of input
that actually made it through exactly that bureaucracy I am talking about
holding back contributors! Well done! Certainly the number is zero, that's
what I try to tell you. 

I actually talk about those people that *did not* invest the time to
contribute their JavaFX improvents, because they feat that bureaucracy. This
number is what you can gain, and it is much higher.

In fact, the number of people who feel p*-off by the JIRA-change this Summer
is much larger than you would assume. Some of them being well-known in the
JavaFX community, BTW. There are many people willing to contribute, but you
simply ignore them thanks to statistics like those. Actually I assume we're
talking about 100 people only in Germany from what the JUG leaders told me.
Further ignore them if you like. Your choice.

Count just my own JIRA tickets and multiply it by the number of JUGs and you
come near to the real potential that you miss.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
dalibor topic
Sent: Dienstag, 1. Dezember 2015 20:38
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

On 01.12.2015 20:13, Markus KARG wrote:
> anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX
team
> clear about how many contributors you lost by that policy?

I think the number you're looking for is zero, judging by the number of 
'Contributed-by' changesets in the rt repository in the last 12 months.[0]

In fact, the number of such changesets has increased significantly after 
the migration to JIRA back in June. Looks like the objective reality is 
quite different from subjective perception. ;)

cheers,
dalibor topic

[0] 
http://hg.openjdk.java.net/openjfx/9-dev/rt/search/?rev=contributed-by
unt=40
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

RE: Future of JavaFX

[Markus KARG]

Speaking of promotion an VW, does it make the Golf an outdated car just because 
they stopped TV marketing in Germany because their sales is running quite well 
still? ;-)

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Tom Eugelink
Sent: Montag, 30. November 2015 22:53
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

There indeed seems to be negative buzz around JavaFX, and Oracle stopping with 
promoting it, is indeed confusing, at the very least. And it is noticeable 
everywhere; without wanting to wine, I really do have a nice JavaFX / JFXtras 
presentation, but it being declined on all conferences for me is a signal about 
the interest of the community in JavaFX. And let's be honest, Oracle's whole 
"let's do cloud and forget there are companies doing this many many years 
already" U turn is not contributing to the mood as well.

OTOH, from what I hear VW has chosen to use JavaFX for it's in car systems. And 
I have just been on an interview for a traffic management system where they 
chose JavaFX over web based. So there also is adoption. But it will be slow. My 
gut says: give it time, and a bit of TLC promotionwise would not be bad.

Tom

On 30-11-2015 21:35, Florian Brunner wrote:
> I read this article as well some days ago. It has some very valid points, but
> all in all I think JavaFX is still the best option out there.
>
> That said I was quite surprised that I got confronted today with the very same
> article by colleagues of mine who are in charge with company-wide adoption of
> various technologies. They tend to agree with the article. Currently JavaFX is
> still just on our technology radar, but not promoted yet. And now they start
> thinking JavFX (and probably thus Java on desktop not even speaking about
> mobile platforms) won't make it and it's getting hard to convince them that
> JavaFX is actually a great option.
>
> Now reading this mail of yours, this article really seems to make waves.
>
> -Florian
>
>   
> Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google:
>> Hi there,
>>
>> there has been quite a shake-up in the JavaFX community last week when Shay
>> Almog (Codename One) first responded to a blog of mine
>> (dlemmermann.wordpress.com) with a lot of negative comments regarding
>> JavaFX and its future. He then followed up with a long blog asking the
>> question „Should Oracle Spring-Clean JavaFX“
>> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html
>> ).
>>
>> I do understand that it is often a good strategy to not comment on stuff
>> like this because commenting would just draw attention to it, but we have
>> now reached the point where potential customers are questioning the
>> sustainability of a JavaFX-based solution. They are now wondering if JavaFX
>> will still be around in a few years. In my specific case the customer
>> demands an answer from me and my partners within the next week, and if not
>> convincing they will go with something / someone else. We will loose a
>> contract worth around one million dollars because of one blog written by
>> Shay with no follow-up from Oracle.
>>
>> What is needed is an official statement from Oracle / Oracle employees /
>> JavaFX development team, saying that Oracle is still committed to JavaFX
>> and that it will still be around for a while. Can somebody please do that?
>>
>> Dirk

RE: Future of JavaFX

[Markus KARG]

With respect to TeamFX, the better question is: Are there plans to further
open the project so third party has an easier channel to contribute without
the hazzle of contributor agreements, JIRA accounts, and so on?

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Casall, Alexander
Sent: Montag, 30. November 2015 23:55
To: Donald Smith; openjfx-dev@openjdk.java.net Mailing
Subject: Re: Future of JavaFX

Don, thanks for your important contribution to this thread.

What exactly means oracle continues to develop on fx? What is the roadmap?

If I check the mercurial archives there are 10-12 people working constantly
on FX in this year. The most work was done by a few of them. I'm not sure
whether this is enought to move FX forward to engage more and more adopters.

The core question is, are there any plans to put more ressources on fx?

- Alex


From: Donald Smith
Sent: 30.11.15, 17:35
To: openjfx-dev@openjdk.java.net Mailing
Subject: Re: Future of JavaFX
Oracle is still committed to JavaFX and it will still be around for a while.

As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% of
the code, we continue developing for it, etc.  I understand that while there
is both Swing and JavaFX available that people will continue to question the
existence of each -- so be it.  Each has it's own niches and benefits and
our strategy, as it has been for years now, is to continue with each.

  - Don


On 30/11/2015 11:13 AM, Dirk @ Google wrote:
> Hi there,
>
> there has been quite a shake-up in the JavaFX community last week when
Shay Almog (Codename One) first responded to a blog of mine
(https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>).
>
> I do understand that it is often a good strategy to not comment on stuff
like this because commenting would just draw attention to it, but we have
now reached the point where potential customers are questioning the
sustainability of a JavaFX-based solution. They are now wondering if JavaFX
will still be around in a few years. In my specific case the customer
demands an answer from me and my partners within the next week, and if not
convincing they will go with something / someone else. We will loose a
contract worth around one million dollars because of one blog written by
Shay with no follow-up from Oracle.
>
> What is needed is an official statement from Oracle / Oracle employees /
JavaFX development team, saying that Oracle is still committed to JavaFX and
that it will still be around for a while. Can somebody please do that?
>
> Dirk
>
>

RE: JavaFX dependency injection

[Markus KARG]

I think this issue identifies a problem caused by a deeper level of the Java 
stack: When will CDI become part of Java SE?

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Nitin Malik
Sent: Samstag, 21. November 2015 23:00
To: openjfx-dev@openjdk.java.net
Subject: JavaFX dependency injection

This was asked recently (
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html)
but I didnt see this addressed.

Are there plans to have better integration with DI frameworks for views and 
controllers?

For example, we have scenarios where multiple instances of the same view and 
controllers need to instantiated with different values. This is a frequent 
question that pops up on Stackoverflow and there apparently is no standard 
answer. It would help if suggested recipes and guidelines are made available.

The solutions we have adopted -
1. Use a controller factory to lookup Spring bean (this isnt ideal because the 
factory needs to be aware of the bean name).
1a. For singleton controllers, the lookup can be done via class name.
2. Use a controller factory that holds a reference to a controller that was 
constructed in code with the various parameters.
3. An Afterburner-like framework that scans controller for an annotation and 
injects the values.

Regards,
Nitin

RE: Missing Mac APIs in JavaFX

[Markus KARG]

Side note: First launching a JavaFX application and then sending a 
file-open-event afterwards is also something Windows does since decades. 
Whether or not the old (file name paramater) or new (OLE event) method is used 
can be customized by the administrator for every single file type. So adding 
support for this actually is not Mac OS specific.

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Dr. Michael Paus
Sent: Sonntag, 8. November 2015 09:10
To: openjfx-dev@openjdk.java.net
Subject: Re: Missing Mac APIs in JavaFX

Hi,

I agree with you that these things should work as expected with JavaFX. 
Have you filed a bug report for them?
In addition to the platform specific APIs I would prefer a common 
solution for common things though, like opening
a file which is associated with your application.

Michael

Am 04.11.15 um 04:41 schrieb Neil Brown:
> Hi,
>
> Short version: I believe JavaFX is lacking some Mac-related APIs which 
> cannot be worked around without an internal com.sun.* call, and would 
> like to request that the APIs be added/made public for JDK 9, perhaps 
> as part of Jonathan Giles' work around JEP 253.
>
> I stand to be corrected on any of this...
>
> Long version: On Windows and Linux, files are generally opened via 
> command-line arguments.  On Mac, there is a file-open event issued to 
> an application, e.g. you double-click a .txt file, TextEdit gets a 
> file-open event.  If TextEdit is not open, it will be launched, then a 
> file-open event will be sent to it.
>
> Pre-JavaFX, the Java solution to receive these events was to use the 
> com.apple.eawt.* packages, which Oracle added in JDK 7. However, it 
> seems that these APIs don't play nice with FX.
>
> I've put some source code at the end of the email for a simple 
> application which I bundled with infinitekind's appbundler fork for 
> testing (https://bitbucket.org/infinitekind/appbundler/).  No matter 
> where you uncomment the setEAWTFileHandler call (search AAA, or BBB in 
> the source), the .app always misses the initial load event which 
> caused the application to open.  The net result is if the user 
> double-clicks an associated file, the JavaFX application will launch, 
> but not load the file in question unless the user double-clicks it 
> again.  Needless to say, this is problematic.
>
> If you look at the FX source code, you can see that FX does set a 
> file-open event handler with an empty implementation 
> (com.sun.glass.ui.Application, line 83 in 8u60).  Grepping the source 
> code shows this method is not implemented anywhere in the source code, 
> so FX is simply discarding the event.  The only Java way I've found to 
> let an FX application listen to the open files event is using a 
> com.sun call in the Application constructor (see CCC in the source, 
> and setFXFileHandler).  Suggestions for a better work-around very 
> welcome!
>
>
> The second API is a similar problem.  JavaFX installs an application 
> menu with standard options, including "Quit" (bound to Cmd-Q).  If you 
> leave Platform.setImplicitExit to its default value of true, all is 
> well.  Cmd-Q quits the application. However, if you 
> setImplicitExit(false) (see YYY in the source), as our actual 
> application must, problems arise.  The quit handler now is a no-op, 
> with no way of overriding it.  Pressing Cmd-Q or right-clicking the 
> dock and selecting quit is now totally ignored by the application, and 
> from the user's perspective the app is unquittable by these normal 
> means.  The only work-around I've found is to set a quit handler in 
> the same spot we set the file open handler (see ZZZ in the source: 
> I've used Platform.exit for this example, in reality we have a nicer 
> custom shutdown routine).
>
>
> My proposal is fairly straight-forward: the 
> com.sun.glass.ui.Application.EventHandler class (and associated 
> setEventHandler call) needs to become a public API in JDK 9, or else 
> these issues will be impossible to work around post-modularisation. 
> Initial file open and quit handler are the only ones biting us at the 
> moment, but I suspect that whole handler class should be public, 
> either as-is or by repurposing it into an EventHandler with some sort 
> of AppEvent extends Event class.
>
> Thanks,
>
> Neil.
>
> ==
> src/example/OpenApp.java
> ==
> package example;
>
> import java.io.File;
> import java.util.ArrayList;
> import java.util.Arrays;
> import java.util.List;
> import java.util.stream.Collectors;
> import javafx.application.Application;
> import javafx.application.Platform;
> import javafx.collections.FXCollections;
> import javafx.collections.ListChangeListener;
> import javafx.collections.ObservableList;
> import javafx.scene.Scene;
> import javafx.scene.control.Label;
> import javafx.scene.control.Menu;
> import javafx.scene.control.MenuBar;
> import javafx.scene.layout.BorderPane;
> import javafx.stage.Stage;
>
> public class OpenApp