Re: Planning for JavaFX.next

[Felix Bembrick]

I think what Abu says here is a good concept to apply more "globally".

I believe there should be a way to get access to the native APIs or contexts 
"in general" across all of the main JavaFX features (such as the OpenGL context 
etc.), just in case you find yourself in a situation where the "standard" 
JavaFX functionality just doesn't quite fit with your use case and you need to 
override or "do something special".

Yes, it would/may not be true cross platform code but sometimes (as has already 
been mentioned several times), you really do need to do some more 
platform-specific low-level stuff and it would be great to have some form of 
"JavaFX Native API Access" feature/concept.

> On 10 Dec. 2016, at 01:31, Abu Abdullah  wrote:
> 
> - RTSP support for MediaPlayer
> - expose gstreamer API for public that allows you to build the pipeline 
> yourself

Re: Planning for JavaFX.next

[Felix Bembrick]

Rather than a "GLNode", I'm a strong advocate for a more API-agnostic "3D 
Canvas Node", given that JavaFX supports both OpenGL and Direct 3D currently 
(and one would expert Vulkan as well in the longer run).

But such a node type is IMHO absolutely critical for JavaFX and, for me, is the 
most obvious "missing feature" for a hardware-accelerated graphics toolkit.

Felix

> On 9 Dec. 2016, at 20:53, Nikos132  wrote:
> 
> Hi again,
> 
> I really miss a way to reuse all the OpenGL (jogamp) code developed for
> many years.
> 
> A kind of GLNode would be nice, and maybe the jogamp community could be
> ready to contribute?
> 
> 
> Erik De Rijcke's  answer really speaks to me since I've experienced very
> poor performances with the basic SwingNode solution and maintenance
> problems with exotic tries to access GL context from Prism.
> 
> Regards
> 
> 2016-12-09 9:21 GMT+01:00 Matthieu BROUILLARD :
> 
>> Hi Folks,
>> 
>> for us in my company I would said the most important topics are related to
>> performances:
>> 
>> * CSS performances
>> * TableView performances
>> * ensure correctness, including memory leaks, of software-rendering
>> pipeline (lot of our customers use Citrix farms with no GPU acceleration)
>> 
>> for everything related to webview (we embed lot of webapps in our client
>> side java container) it is a bit late for us we are currently switching to
>> JxBrowser.
>> 
>> Matthieu Brouillard
>> 
>> 
>> On Thu, Dec 8, 2016 at 12:45 AM, Jonathan Giles >> 
>> wrote:
>> 
>>> 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: Planning for JavaFX.next

[Felix Bembrick]

How about:

1. Greatly enhanced 3D support including (but not limited to) a 3D Canvas.

2. Significantly increased scene graph rendering performance (it may have been 
done already).

3. Official mobile and embedded support (without having to rely on Gluon etc., 
even though they are doing a fantastic job).

4. Bring back Scene Builder and add full support for all types of apps 
including animations etc.

5. Not just WebGL support but proper Chromium adoption instead of WebKit to get 
full HTML5 compatibility.

6. Greatly expanded media formats supported for video and audio.

7. Professional deployment tool that enables packaging, installation and 
auto-updates with appropriate look and feel for each major OS and for this 
deployment kit to be integrated into all major IDEs. This should probably be my 
number 1.

Felix

> On 8 Dec. 2016, at 10:45, Jonathan Giles  wrote:
> 
> 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: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Sorry, the "agreed" comment was meant to be a reply to you Tobi.

Pity not everyone "agrees"...

> On 28 Nov. 2016, at 19:10, Tobi <t...@ultramixer.com> wrote:
> 
> We should discuss a new rendering pipeline on the openjfx mailing list. It’s 
> not off topic - it’s an important topic for the future of JavaFX.
> 
> 
>> Am 28.11.2016 um 06:54 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> Sorry Gerrit - you did indeed.
>> 
>> Maybe you'd also like to participate in the offline discussion (especially 
>> now that you don't work for Oracle)?
>> 
>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>> 
>>> Well I mentioned before that I'm interested too :)
>>> 
>>> Cheers,
>>> 
>>> Gerrit
>>> 
>>> 
>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>> <felix.bembr...@gmail.com>:
>>>> Well, given that you and Benjamin seem to be the only people interested in 
>>>> it, perhaps we should discuss it offline (so as not to bother Oracle or 
>>>> spam list this)...
>>>> 
>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>> 
>>>>> Where can we read more about your HPR renderer?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>>>> 
>>>>>> Short answer? Maybe.
>>>>>> 
>>>>>> But exactly one more word than any from Oracle ;-)
>>>>>> 
>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> A very short answer ;) ….
>>>>>>> 
>>>>>>> Do you have any URL?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick 
>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>> 
>>>>>>>> Yes.
>>>>>>>> 
>>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR 
>>>>>>>>> with JavaFX?
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Tobi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick 
>>>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>>>> 
>>>>>>>>>> Thanks Laurent,
>>>>>>>>>> 
>>>>>>>>>> That's another thing we discovered: using Java itself in the most 
>>>>>>>>>> performant way can help a lot.
>>>>>>>>>> 
>>>>>>>>>> It can be tricky, but profiling can often highlight various patterns 
>>>>>>>>>> of object instantiation that show-up red flags and can lead you 
>>>>>>>>>> directly to regions of the code that can be refactored to be 
>>>>>>>>>> significantly more efficient.
>>>>>>>>>> 
>>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar 
>>>>>>>>>> discoveries and remedies.
>>>>>>>>>> 
>>>>>>>>>> Blessings,
>>>>>>>>>> 
>>>>>>>>>> Felix
>>>>>>>>>> 
>>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès 
>>>>>>>>>>> <bourges.laur...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully 
>>>>>>>>>>> avoided any both array

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Agreed.

> On 28 Nov. 2016, at 19:08, Michael Paus <m...@jugs.org> wrote:
> 
>> Am 28.11.16 um 08:51 schrieb Felix Bembrick:
>> Great - good to see interest growing.
>> 
>> Especially given that you work for Oracle, right?
> Sorry, if I have to disappoint you on that but I do not work for Oracle.
> I run my own little company and are the head of the Java User Group Stuttgart.
> <http://www.jugs.de/>
>> 
>>> On 28 Nov. 2016, at 18:10, Michael Paus <m...@jugs.org> wrote:
>>> 
>>> I am interested too although I have only been listening quietly so far due 
>>> to lack of time.
>>> Cheers
>>> Michael
>>> 
>>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick:
>>>> Sorry Gerrit - you did indeed.
>>>> 
>>>> Maybe you'd also like to participate in the offline discussion (especially 
>>>> now that you don't work for Oracle)?
>>>> 
>>>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>>>> 
>>>>> Well I mentioned before that I'm interested too :)
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Gerrit
>>>>> 
>>>>> 
>>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>>>> <felix.bembr...@gmail.com>:
>>>>>> Well, given that you and Benjamin seem to be the only people interested 
>>>>>> in it, perhaps we should discuss it offline (so as not to bother Oracle 
>>>>>> or spam list this)...
>>>>>> 
>>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> Where can we read more about your HPR renderer?
>> Am 28.11.16 um 08:51 schrieb Felix Bembrick:
>> 
>> Great - good to see interest growing.
>> 
>> Especially given that you work for Oracle, right?
> Sorry, if I have to disappoint you on that but I do not work for Oracle.
> I run my own little company and are the head of the Java User Group Stuttgart.
> <http://www.jugs.de/>
>> 
>>> On 28 Nov. 2016, at 18:10, Michael Paus <m...@jugs.org> wrote:
>>> 
>>> I am interested too although I have only been listening quietly so far due 
>>> to lack of time.
>>> Cheers
>>> Michael
>>> 
>>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick:
>>>> Sorry Gerrit - you did indeed.
>>>> 
>>>> Maybe you'd also like to participate in the offline discussion (especially 
>>>> now that you don't work for Oracle)?
>>>> 
>>>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>>>> 
>>>>> Well I mentioned before that I'm interested too :)
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Gerrit
>>>>> 
>>>>> 
>>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>>>> <felix.bembr...@gmail.com>:
>>>>>> Well, given that you and Benjamin seem to be the only people interested 
>>>>>> in it, perhaps we should discuss it offline (so as not to bother Oracle 
>>>>>> or spam list this)...
>>>>>> 
>>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> Where can we read more about your HPR renderer?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick 
>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>> 
>>>>>>>> Short answer? Maybe.
>>>>>>>> 
>>>>>>>> But exactly one more word than any from Oracle ;-)
>>>>>>>> 
>>>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>>>>>>>> 
>>>>>>>>> A very short answer ;) ….
>>>>>>>>> 
>>>>>>>>> Do you have any URL?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick 
>>>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>&

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

No disappointment, no surprises.

It was a rhetorical question...

> On 28 Nov. 2016, at 19:08, Michael Paus <m...@jugs.org> wrote:
> 
>> Am 28.11.16 um 08:51 schrieb Felix Bembrick:
>> Great - good to see interest growing.
>> 
>> Especially given that you work for Oracle, right?
> Sorry, if I have to disappoint you on that but I do not work for Oracle.
> I run my own little company and are the head of the Java User Group Stuttgart.
> <http://www.jugs.de/>
>> 
>>> On 28 Nov. 2016, at 18:10, Michael Paus <m...@jugs.org> wrote:
>>> 
>>> I am interested too although I have only been listening quietly so far due 
>>> to lack of time.
>>> Cheers
>>> Michael
>>> 
>>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick:
>>>> Sorry Gerrit - you did indeed.
>>>> 
>>>> Maybe you'd also like to participate in the offline discussion (especially 
>>>> now that you don't work for Oracle)?
>>>> 
>>>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>>>> 
>>>>> Well I mentioned before that I'm interested too :)
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Gerrit
>>>>> 
>>>>> 
>>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>>>> <felix.bembr...@gmail.com>:
>>>>>> Well, given that you and Benjamin seem to be the only people interested 
>>>>>> in it, perhaps we should discuss it offline (so as not to bother Oracle 
>>>>>> or spam list this)...
>>>>>> 
>>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> Where can we read more about your HPR renderer?
>> Am 28.11.16 um 08:51 schrieb Felix Bembrick:
>> 
>> Great - good to see interest growing.
>> 
>> Especially given that you work for Oracle, right?
> Sorry, if I have to disappoint you on that but I do not work for Oracle.
> I run my own little company and are the head of the Java User Group Stuttgart.
> <http://www.jugs.de/>
>> 
>>> On 28 Nov. 2016, at 18:10, Michael Paus <m...@jugs.org> wrote:
>>> 
>>> I am interested too although I have only been listening quietly so far due 
>>> to lack of time.
>>> Cheers
>>> Michael
>>> 
>>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick:
>>>> Sorry Gerrit - you did indeed.
>>>> 
>>>> Maybe you'd also like to participate in the offline discussion (especially 
>>>> now that you don't work for Oracle)?
>>>> 
>>>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>>>> 
>>>>> Well I mentioned before that I'm interested too :)
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Gerrit
>>>>> 
>>>>> 
>>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>>>> <felix.bembr...@gmail.com>:
>>>>>> Well, given that you and Benjamin seem to be the only people interested 
>>>>>> in it, perhaps we should discuss it offline (so as not to bother Oracle 
>>>>>> or spam list this)...
>>>>>> 
>>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> Where can we read more about your HPR renderer?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick 
>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>> 
>>>>>>>> Short answer? Maybe.
>>>>>>>> 
>>>>>>>> But exactly one more word than any from Oracle ;-)
>>>>>>>> 
>>>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>>>>>>>> 
>>>>>>>>> A very short answer ;) ….
>>>>>>>>> 
>>>>>>>>> Do you have any URL?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick 
>>&g

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Great - good to see interest growing.

Especially given that you work for Oracle, right?

> On 28 Nov. 2016, at 18:10, Michael Paus <m...@jugs.org> wrote:
> 
> I am interested too although I have only been listening quietly so far due to 
> lack of time.
> Cheers
> Michael
> 
>> Am 28.11.16 um 06:54 schrieb Felix Bembrick:
>> Sorry Gerrit - you did indeed.
>> 
>> Maybe you'd also like to participate in the offline discussion (especially 
>> now that you don't work for Oracle)?
>> 
>>> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
>>> 
>>> Well I mentioned before that I'm interested too :)
>>> 
>>> Cheers,
>>> 
>>> Gerrit
>>> 
>>> 
>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
>>> <felix.bembr...@gmail.com>:
>>>> Well, given that you and Benjamin seem to be the only people interested in 
>>>> it, perhaps we should discuss it offline (so as not to bother Oracle or 
>>>> spam list this)...
>>>> 
>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>>>> 
>>>>> Where can we read more about your HPR renderer?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>>>> 
>>>>>> Short answer? Maybe.
>>>>>> 
>>>>>> But exactly one more word than any from Oracle ;-)
>>>>>> 
>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> A very short answer ;) ….
>>>>>>> 
>>>>>>> Do you have any URL?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick 
>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>> 
>>>>>>>> Yes.
>>>>>>>> 
>>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR 
>>>>>>>>> with JavaFX?
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Tobi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick 
>>>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>>>> 
>>>>>>>>>> Thanks Laurent,
>>>>>>>>>> 
>>>>>>>>>> That's another thing we discovered: using Java itself in the most 
>>>>>>>>>> performant way can help a lot.
>>>>>>>>>> 
>>>>>>>>>> It can be tricky, but profiling can often highlight various patterns 
>>>>>>>>>> of object instantiation that show-up red flags and can lead you 
>>>>>>>>>> directly to regions of the code that can be refactored to be 
>>>>>>>>>> significantly more efficient.
>>>>>>>>>> 
>>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar 
>>>>>>>>>> discoveries and remedies.
>>>>>>>>>> 
>>>>>>>>>> Blessings,
>>>>>>>>>> 
>>>>>>>>>> Felix
>>>>>>>>>> 
>>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès 
>>>>>>>>>>> <bourges.laur...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully 
>>>>>>>>>>> avoided any both array allocation (byte/int/float pools) and also 
>>>>>>>>>>> reduced array 

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Sorry Gerrit - you did indeed.

Maybe you'd also like to participate in the offline discussion (especially now 
that you don't work for Oracle)?

> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote:
> 
> Well I mentioned before that I'm interested too :)
> 
> Cheers,
> 
> Gerrit
> 
> 
> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick 
> <felix.bembr...@gmail.com>:
>> Well, given that you and Benjamin seem to be the only people interested in 
>> it, perhaps we should discuss it offline (so as not to bother Oracle or spam 
>> list this)...
>> 
>>> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
>>> 
>>> Where can we read more about your HPR renderer?
>>> 
>>> 
>>> 
>>> 
>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>> 
>>>> Short answer? Maybe.
>>>> 
>>>> But exactly one more word than any from Oracle ;-)
>>>> 
>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>>>> 
>>>>> A very short answer ;) ….
>>>>> 
>>>>> Do you have any URL?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR 
>>>>>>> with JavaFX?
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Tobi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick 
>>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>>> 
>>>>>>>> Thanks Laurent,
>>>>>>>> 
>>>>>>>> That's another thing we discovered: using Java itself in the most 
>>>>>>>> performant way can help a lot.
>>>>>>>> 
>>>>>>>> It can be tricky, but profiling can often highlight various patterns 
>>>>>>>> of object instantiation that show-up red flags and can lead you 
>>>>>>>> directly to regions of the code that can be refactored to be 
>>>>>>>> significantly more efficient.
>>>>>>>> 
>>>>>>>> Also, the often overlooked GC log analysis can lead to similar 
>>>>>>>> discoveries and remedies.
>>>>>>>> 
>>>>>>>> Blessings,
>>>>>>>> 
>>>>>>>> Felix
>>>>>>>> 
>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès 
>>>>>>>>> <bourges.laur...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully 
>>>>>>>>> avoided any both array allocation (byte/int/float pools) and also 
>>>>>>>>> reduced array copies or clean up ie only clear dirty parts.
>>>>>>>>> 
>>>>>>>>> This approach is generic and could be applied in other critical 
>>>>>>>>> places of the rendering pipelines.
>>>>>>>>> 
>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer:
>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
>>>>>>>>> 
>>>>>>>>> Of course I would be happy to share my experience and work with a 
>>>>>>>>> tiger team on optimizing JavaFX graphics.
>>>>>>>>> 
>>>>>>>>> However I would like getting sort of sponsoring for my potential 
>>>>>>>>> contributions...
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Laurent
>>>>>>>>> 
>>>>&g

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Well, given that you and Benjamin seem to be the only people interested in it, 
perhaps we should discuss it offline (so as not to bother Oracle or spam list 
this)...

> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote:
> 
> Where can we read more about your HPR renderer?
> 
> 
> 
> 
>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> Short answer? Maybe.
>> 
>> But exactly one more word than any from Oracle ;-)
>> 
>>> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
>>> 
>>> A very short answer ;) ….
>>> 
>>> Do you have any URL?
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>> 
>>>> Yes.
>>>> 
>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with 
>>>>> JavaFX?
>>>>> 
>>>>> Best regards,
>>>>> Tobi
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>>>> 
>>>>>> Thanks Laurent,
>>>>>> 
>>>>>> That's another thing we discovered: using Java itself in the most 
>>>>>> performant way can help a lot.
>>>>>> 
>>>>>> It can be tricky, but profiling can often highlight various patterns of 
>>>>>> object instantiation that show-up red flags and can lead you directly to 
>>>>>> regions of the code that can be refactored to be significantly more 
>>>>>> efficient.
>>>>>> 
>>>>>> Also, the often overlooked GC log analysis can lead to similar 
>>>>>> discoveries and remedies.
>>>>>> 
>>>>>> Blessings,
>>>>>> 
>>>>>> Felix
>>>>>> 
>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully 
>>>>>>> avoided any both array allocation (byte/int/float pools) and also 
>>>>>>> reduced array copies or clean up ie only clear dirty parts.
>>>>>>> 
>>>>>>> This approach is generic and could be applied in other critical places 
>>>>>>> of the rendering pipelines.
>>>>>>> 
>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer:
>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
>>>>>>> 
>>>>>>> Of course I would be happy to share my experience and work with a tiger 
>>>>>>> team on optimizing JavaFX graphics.
>>>>>>> 
>>>>>>> However I would like getting sort of sponsoring for my potential 
>>>>>>> contributions...
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Laurent
>>>>>>> 
>>>>>>> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the 
>>>>>>>> community!
>>>>>>>> 
>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX 
>>>>>>>> rendering performance. I can confirm that the performance of JavaFX 
>>>>>>>> scene graph is not there where it should be. So multithreading would 
>>>>>>>> be an excellent, but difficult approach.
>>>>>>>> 
>>>>>>>> Felix, concerning your research of other toolkits: Do they all use 
>>>>>>>> multithreading or are there any toolkits which use single threading 
>>>>>>>> but are faster than JavaFX?
>>>>>>>> 
>>>>>>>> So maybe there are other points 

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Short answer? Maybe.

But exactly one more word than any from Oracle ;-)

> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote:
> 
> A very short answer ;) ….
> 
> Do you have any URL?
> 
> 
> 
> 
> 
>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> Yes.
>> 
>>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
>>> 
>>> Hi,
>>> 
>>> @Felix: Is there any Github project, demo video or trial to test HPR with 
>>> JavaFX?
>>> 
>>> Best regards,
>>> Tobi
>>> 
>>> 
>>> 
>>> 
>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>> 
>>>> Thanks Laurent,
>>>> 
>>>> That's another thing we discovered: using Java itself in the most 
>>>> performant way can help a lot.
>>>> 
>>>> It can be tricky, but profiling can often highlight various patterns of 
>>>> object instantiation that show-up red flags and can lead you directly to 
>>>> regions of the code that can be refactored to be significantly more 
>>>> efficient.
>>>> 
>>>> Also, the often overlooked GC log analysis can lead to similar discoveries 
>>>> and remedies.
>>>> 
>>>> Blessings,
>>>> 
>>>> Felix
>>>> 
>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided 
>>>>> any both array allocation (byte/int/float pools) and also reduced array 
>>>>> copies or clean up ie only clear dirty parts.
>>>>> 
>>>>> This approach is generic and could be applied in other critical places of 
>>>>> the rendering pipelines.
>>>>> 
>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer:
>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
>>>>> 
>>>>> Of course I would be happy to share my experience and work with a tiger 
>>>>> team on optimizing JavaFX graphics.
>>>>> 
>>>>> However I would like getting sort of sponsoring for my potential 
>>>>> contributions...
>>>>> 
>>>>> Cheers,
>>>>> Laurent
>>>>> 
>>>>> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the 
>>>>>> community!
>>>>>> 
>>>>>> I am happy to see starting a discussion about boosting up the JavaFX 
>>>>>> rendering performance. I can confirm that the performance of JavaFX 
>>>>>> scene graph is not there where it should be. So multithreading would be 
>>>>>> an excellent, but difficult approach.
>>>>>> 
>>>>>> Felix, concerning your research of other toolkits: Do they all use 
>>>>>> multithreading or are there any toolkits which use single threading but 
>>>>>> are faster than JavaFX?
>>>>>> 
>>>>>> So maybe there are other points than multithreading where we can boost 
>>>>>> the performance?
>>>>>> 
>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark 
>>>>>> with your HPR?
>>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Tobi
>>>>>> 
>>>>>> 
>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick 
>>>>>>> <felix.bembr...@gmail.com>:
>>>>>>> 
>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse).
>>>>>>> 
>>>>>>> So, with all the recent discussions regarding the great contribution by
>>>>>>> Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in
>>>>>>> general.
>>>>>>> 
>>>>>>> As has been correctly pointed-out, conver

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Thanks Benjamin,

We studied those products you mentioned when designing HPR and, yes, there is 
extensive use of shaders and much more utilisation of the GPU in general.

We also have the beginnings of a Vulkan-only version written in 
(coincidentally) Rust which is showing amazing promise. Vulkan is something we 
are investing a lot of research and effort into.

Felix

> On 25 Nov. 2016, at 22:25, Benjamin Gudehus <hasteb...@gmail.com> wrote:
> 
> Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem 
> to really fit into what needs to be done to improve the performance.
> 
> Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering or 
> does this only apply to rasterization (i.e. Marlin)? 
> 
> Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot, along 
> with parallelized DOM (scene graph) access, aggressive culling and caching 
> and batching.
> 
> --Benjamin
> 
>> On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley <b...@jpro.io> wrote:
>> Hi,
>> 
>> @Felix: Is there any Github project, demo video or trial to test HPR with 
>> JavaFX?
>> 
>> Best regards,
>> Tobi
>> 
>> 
>> 
>> 
>> > Am 11.11.2016 um 12:08 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> >
>> > Thanks Laurent,
>> >
>> > That's another thing we discovered: using Java itself in the most 
>> > performant way can help a lot.
>> >
>> > It can be tricky, but profiling can often highlight various patterns of 
>> > object instantiation that show-up red flags and can lead you directly to 
>> > regions of the code that can be refactored to be significantly more 
>> > efficient.
>> >
>> > Also, the often overlooked GC log analysis can lead to similar discoveries 
>> > and remedies.
>> >
>> > Blessings,
>> >
>> > Felix
>> >
>> >> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> 
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> To optimize Pisces that became the Marlin rasterizer, I carefully avoided 
>> >> any both array allocation (byte/int/float pools) and also reduced array 
>> >> copies or clean up ie only clear dirty parts.
>> >>
>> >> This approach is generic and could be applied in other critical places of 
>> >> the rendering pipelines.
>> >>
>> >> FYI here are my fosdem 2016 slides on the Marlin renderer:
>> >> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
>> >>
>> >> Of course I would be happy to share my experience and work with a tiger 
>> >> team on optimizing JavaFX graphics.
>> >>
>> >> However I would like getting sort of sponsoring for my potential 
>> >> contributions...
>> >>
>> >> Cheers,
>> >> Laurent
>> >>
>> >> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
>> >>>
>> >>> Hi,
>> >>>
>> >>> thanks Felix, Laurent and Chris for sharing your stuff with the 
>> >>> community!
>> >>>
>> >>> I am happy to see starting a discussion about boosting up the JavaFX 
>> >>> rendering performance. I can confirm that the performance of JavaFX 
>> >>> scene graph is not there where it should be. So multithreading would be 
>> >>> an excellent, but difficult approach.
>> >>>
>> >>> Felix, concerning your research of other toolkits: Do they all use 
>> >>> multithreading or are there any toolkits which use single threading but 
>> >>> are faster than JavaFX?
>> >>>
>> >>> So maybe there are other points than multithreading where we can boost 
>> >>> the performance?
>> >>>
>> >>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark 
>> >>> with your HPR?
>> >>>
>> >>>
>> >>> Best regards,
>> >>> Tobi
>> >>>
>> >>>
>> >>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick 
>> >>>> <felix.bembr...@gmail.com>:
>> >>>>
>> >>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse).
>> >>>>
>> >>>> So, with all the recent discussions regarding the great contribution by
>&g

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Yes.

> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote:
> 
> Hi,
> 
> @Felix: Is there any Github project, demo video or trial to test HPR with 
> JavaFX?
> 
> Best regards,
> Tobi
> 
> 
> 
> 
>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> Thanks Laurent,
>> 
>> That's another thing we discovered: using Java itself in the most performant 
>> way can help a lot.
>> 
>> It can be tricky, but profiling can often highlight various patterns of 
>> object instantiation that show-up red flags and can lead you directly to 
>> regions of the code that can be refactored to be significantly more 
>> efficient.
>> 
>> Also, the often overlooked GC log analysis can lead to similar discoveries 
>> and remedies.
>> 
>> Blessings,
>> 
>> Felix
>> 
>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided 
>>> any both array allocation (byte/int/float pools) and also reduced array 
>>> copies or clean up ie only clear dirty parts.
>>> 
>>> This approach is generic and could be applied in other critical places of 
>>> the rendering pipelines.
>>> 
>>> FYI here are my fosdem 2016 slides on the Marlin renderer:
>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
>>> 
>>> Of course I would be happy to share my experience and work with a tiger 
>>> team on optimizing JavaFX graphics.
>>> 
>>> However I would like getting sort of sponsoring for my potential 
>>> contributions...
>>> 
>>> Cheers,
>>> Laurent
>>> 
>>> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community!
>>>> 
>>>> I am happy to see starting a discussion about boosting up the JavaFX 
>>>> rendering performance. I can confirm that the performance of JavaFX scene 
>>>> graph is not there where it should be. So multithreading would be an 
>>>> excellent, but difficult approach.
>>>> 
>>>> Felix, concerning your research of other toolkits: Do they all use 
>>>> multithreading or are there any toolkits which use single threading but 
>>>> are faster than JavaFX?
>>>> 
>>>> So maybe there are other points than multithreading where we can boost the 
>>>> performance?
>>>> 
>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark 
>>>> with your HPR?
>>>> 
>>>> 
>>>> Best regards,
>>>> Tobi
>>>> 
>>>> 
>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>>> 
>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse).
>>>>> 
>>>>> So, with all the recent discussions regarding the great contribution by
>>>>> Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in
>>>>> general.
>>>>> 
>>>>> As has been correctly pointed-out, converting or modifying the existing
>>>>> rendering pipeline into a fully multi-threaded and performant beast is
>>>>> indeed quite a complex task.
>>>>> 
>>>>> But, that's exactly what myself and my colleagues have been working on for
>>>>> about 2 years.
>>>>> 
>>>>> The result is what we call the Hyper Rendering Pipeline (HPR).
>>>>> 
>>>>> Work on HPR started when we developed FXMark and were (bitterly)
>>>>> disappointed with the performance of the JavaFX scene graph.  Many JavaFX
>>>>> developers have blogged about the need to dramatically minimise the number
>>>>> of nodes (especially on embedded devices) in order to achieve even
>>>>> "acceptable" performance.  Often it is the case that most (if not all
>>>>> rendering) is eventually done in a single Canvas node.
>>>>> 
>>>>> Now, as well already know, the JavaFX Canvas does perform very well and 
>>>>> the
>>>&g

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Thanks Laurent,

That's another thing we discovered: using Java itself in the most performant 
way can help a lot.

It can be tricky, but profiling can often highlight various patterns of object 
instantiation that show-up red flags and can lead you directly to regions of 
the code that can be refactored to be significantly more efficient.

Also, the often overlooked GC log analysis can lead to similar discoveries and 
remedies.

Blessings,

Felix

> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> wrote:
> 
> Hi,
> 
> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any 
> both array allocation (byte/int/float pools) and also reduced array copies or 
> clean up ie only clear dirty parts.
> 
> This approach is generic and could be applied in other critical places of the 
> rendering pipelines.
> 
> FYI here are my fosdem 2016 slides on the Marlin renderer:
> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
> 
> Of course I would be happy to share my experience and work with a tiger team 
> on optimizing JavaFX graphics.
> 
> However I would like getting sort of sponsoring for my potential 
> contributions...
> 
> Cheers,
> Laurent
> 
> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
> >
> > Hi,
> >
> > thanks Felix, Laurent and Chris for sharing your stuff with the community!
> >
> > I am happy to see starting a discussion about boosting up the JavaFX 
> > rendering performance. I can confirm that the performance of JavaFX scene 
> > graph is not there where it should be. So multithreading would be an 
> > excellent, but difficult approach.
> >
> > Felix, concerning your research of other toolkits: Do they all use 
> > multithreading or are there any toolkits which use single threading but are 
> > faster than JavaFX?
> >
> > So maybe there are other points than multithreading where we can boost the 
> > performance?
> >
> > 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark 
> > with your HPR?
> >
> >
> > Best regards,
> > Tobi
> >
> >
> > > Am 10.11.2016 um 19:11 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
> > >
> > > (Thanks to Kevin for lifting my "awaiting moderation" impasse).
> > >
> > > So, with all the recent discussions regarding the great contribution by
> > > Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
> > > started to discuss parallelisation of the JavaFX rendering pipeline in
> > > general.
> > >
> > > As has been correctly pointed-out, converting or modifying the existing
> > > rendering pipeline into a fully multi-threaded and performant beast is
> > > indeed quite a complex task.
> > >
> > > But, that's exactly what myself and my colleagues have been working on for
> > > about 2 years.
> > >
> > > The result is what we call the Hyper Rendering Pipeline (HPR).
> > >
> > > Work on HPR started when we developed FXMark and were (bitterly)
> > > disappointed with the performance of the JavaFX scene graph.  Many JavaFX
> > > developers have blogged about the need to dramatically minimise the number
> > > of nodes (especially on embedded devices) in order to achieve even
> > > "acceptable" performance.  Often it is the case that most (if not all
> > > rendering) is eventually done in a single Canvas node.
> > >
> > > Now, as well already know, the JavaFX Canvas does perform very well and 
> > > the
> > > recent awesome work (DemoFX) by Chris Newland, just for example, shows 
> > > what
> > > can be done with this one node.
> > >
> > > But, the majority of the animation plumbing in JavaFX is related to the
> > > scene graph itself and is designed to make use of multiple nodes and node
> > > types.  At the moment, the performance of this scene graph is the Achilles
> > > Heel of JavaFX (or at least one of them).
> > >
> > > Enter HPR.
> > >
> > > I personally have worked with a number of hardware-accelerated toolkits
> > > over the years and am astounded by just how sluggish the rendering 
> > > pipeline
> > > for JavaFX is. When I am animating just a couple of hundred nodes using
> > > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on
> > > the same (very powerful) machine, I can use other toolkits to render
> > > thousands of "objects" and achieve frame rates well ov

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

Hi Tobi,

Thanks for the input.

In answer to your first question, not all toolkits use as much parallelisation 
as HPR but are indeed more performant than JavaFX for a few reasons:

1. They are "closer to the metal". The more layers of architecture you add, 
there is almost an inevitable performance hit associated with them. There's an 
OpenGL toolkit named Visualization Library which is very low-level and  the 
performance is outstanding (and is basically single threaded).

2. The structure of the scene graph. The more cumbersome or memory-hogging the 
scene graph along with the actual "scene graph model" used can seriously impair 
the ability to optimise the rendering  pipeline. That's why it was necessary 
for us to restructure the JavaFX scene graph itself.

3. Significant performance improvements can be achieved (even in a single 
threaded pipeline) simply by batching GPU commands or using various forms of 
"caching" them on the GPU (as both OpenGL and Direct3D support). JavaFX is 
particularly poor in this area of CPU-to-GPU communication.

Now, as for testing HPR with DemoFX, the answer is no.

There are 2 main reasons:

1. HPR currently only works with Java/JavaFX 9 (and that is unlikely to change).

2. Given that DemoFX is mostly Canvas based (along with some 3D scene 
overlays), I doubt it would have much impact (although I expect the 3D parts 
would perform better).

I hope these answers are helpful.

Blessings,

Felix

> On 11 Nov. 2016, at 21:27, Tobi <t...@ultramixer.com> wrote:
> 
> Hi,
> 
> thanks Felix, Laurent and Chris for sharing your stuff with the community!
> 
> I am happy to see starting a discussion about boosting up the JavaFX 
> rendering performance. I can confirm that the performance of JavaFX scene 
> graph is not there where it should be. So multithreading would be an 
> excellent, but difficult approach.
> 
> Felix, concerning your research of other toolkits: Do they all use 
> multithreading or are there any toolkits which use single threading but are 
> faster than JavaFX?
> 
> So maybe there are other points than multithreading where we can boost the 
> performance?
> 
> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with 
> your HPR? 
> 
> 
> Best regards,
> Tobi
> 
> 
>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> (Thanks to Kevin for lifting my "awaiting moderation" impasse).
>> 
>> So, with all the recent discussions regarding the great contribution by
>> Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
>> started to discuss parallelisation of the JavaFX rendering pipeline in
>> general.
>> 
>> As has been correctly pointed-out, converting or modifying the existing
>> rendering pipeline into a fully multi-threaded and performant beast is
>> indeed quite a complex task.
>> 
>> But, that's exactly what myself and my colleagues have been working on for
>> about 2 years.
>> 
>> The result is what we call the Hyper Rendering Pipeline (HPR).
>> 
>> Work on HPR started when we developed FXMark and were (bitterly)
>> disappointed with the performance of the JavaFX scene graph.  Many JavaFX
>> developers have blogged about the need to dramatically minimise the number
>> of nodes (especially on embedded devices) in order to achieve even
>> "acceptable" performance.  Often it is the case that most (if not all
>> rendering) is eventually done in a single Canvas node.
>> 
>> Now, as well already know, the JavaFX Canvas does perform very well and the
>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what
>> can be done with this one node.
>> 
>> But, the majority of the animation plumbing in JavaFX is related to the
>> scene graph itself and is designed to make use of multiple nodes and node
>> types.  At the moment, the performance of this scene graph is the Achilles
>> Heel of JavaFX (or at least one of them).
>> 
>> Enter HPR.
>> 
>> I personally have worked with a number of hardware-accelerated toolkits
>> over the years and am astounded by just how sluggish the rendering pipeline
>> for JavaFX is. When I am animating just a couple of hundred nodes using
>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on
>> the same (very powerful) machine, I can use other toolkits to render
>> thousands of "objects" and achieve frame rates well over 1000 FPS.
>> 
>> So, we refactored the entire scene graph rendering pipeline with the
>> following goals and principles:
>> 
>> 1. It is written using JavaFX 9 and Java 9 (but could theore

Optimised, high-performance, multi-threaded rendering pipeline

[Felix Bembrick]

(Thanks to Kevin for lifting my "awaiting moderation" impasse).

So, with all the recent discussions regarding the great contribution by
Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
started to discuss parallelisation of the JavaFX rendering pipeline in
general.

As has been correctly pointed-out, converting or modifying the existing
rendering pipeline into a fully multi-threaded and performant beast is
indeed quite a complex task.

But, that's exactly what myself and my colleagues have been working on for
about 2 years.

The result is what we call the Hyper Rendering Pipeline (HPR).

Work on HPR started when we developed FXMark and were (bitterly)
disappointed with the performance of the JavaFX scene graph.  Many JavaFX
developers have blogged about the need to dramatically minimise the number
of nodes (especially on embedded devices) in order to achieve even
"acceptable" performance.  Often it is the case that most (if not all
rendering) is eventually done in a single Canvas node.

Now, as well already know, the JavaFX Canvas does perform very well and the
recent awesome work (DemoFX) by Chris Newland, just for example, shows what
can be done with this one node.

But, the majority of the animation plumbing in JavaFX is related to the
scene graph itself and is designed to make use of multiple nodes and node
types.  At the moment, the performance of this scene graph is the Achilles
Heel of JavaFX (or at least one of them).

Enter HPR.

I personally have worked with a number of hardware-accelerated toolkits
over the years and am astounded by just how sluggish the rendering pipeline
for JavaFX is. When I am animating just a couple of hundred nodes using
JavaFX and transitions, I am lucky to get more than about 30 FPS, but on
the same (very powerful) machine, I can use other toolkits to render
thousands of "objects" and achieve frame rates well over 1000 FPS.

So, we refactored the entire scene graph rendering pipeline with the
following goals and principles:

1. It is written using JavaFX 9 and Java 9 (but could theoretically be
back-ported to JavaFX 8 though I see no reason to).

2. We analysed how other toolkits had optimised their own rendering
pipelines (especially Qt which has made some significant advances in this
area in recent years).  We also analysed recent examples of multi-threaded
rendering using the new Vulkan API.

3. We carefully analysed and determined which parts of the pipeline should
best utilise the CPU and which parts should best utilise the GPU.

4. For those parts most suited to the CPU, we use the advanced concurrency
features of Java 8/9 to maximise parallelisation and throughput by
utilising multiple cores & threads in as an efficient manner as possible.

5. We devoted a large amount of time to optimising the "communication"
between the CPU and GPU to be far less "chatty" and this alone led to some
huge performance gains.

6. We also looked at the structure of the scene graph itself and after
studying products such as OpenSceneGraph, we refactored the JavaFX scene
graph in such a way that it lends itself to optimised rendering much more
easily.

7. This is clearly not a "small" patch.  In fact to refer to it as a
"patch" is probably rather inappropriate.

The end result is that we now have a fully-functional prototype of HPR and,
already, we are seeing very significant performance improvements.

At the minimum, scene graph rendering performance has improved by 500% and,
with judicious and sometimes "tricky" use of caching, we have seen
improvements in performance of 10x or more.

And... we are only just *starting* with the performance optimisation phase.

The potential for HPR is massive as it opens-up the possibility for the
JavaFX scene graph and the animation/transition infrastructure to be used
for a whole new class of applications including games, advanced
visualisations etc., without having to rely on imperative programming of a
single Canvas node.

I believe that HPR, along with tremendous recent developments like JPro and
the outstanding work by Gluon on mobiles and embedded devices, could
position JavaFX to be the best graphics toolkit of any kind in any language
and, be the ONLY *truly* cross-platform graphics technology available.

WORA for graphics and UIs is finally within reach!

Blessings,

Felix

Re: Marlin-Renderer and JavaFX

[Felix Bembrick]

If Oracle are interested in it (and permit me to be part of the JavaFX 
community on a level playing field), I would be more than happy to!

(Such as not having to wait for every post to be moderated for example).

> On 10 Nov. 2016, at 21:56, Tobias Bley <b...@jpro.io> wrote:
> 
> What about performance benchmark? Did you already tried to benchmark your 
> prototype with DemoFX from Chris Newsland? 
> 
> https://github.com/chriswhocodes/DemoFX 
> <https://github.com/chriswhocodes/DemoFX>
> 
> 
> 
> 
> 
> 
>> Am 10.11.2016 um 08:40 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> Started? I have a fully working prototype!
>> 
>> And it's not just "parallelised" but it greatly improves the efficiency and 
>> utilisation of both the CPU (and cores) and the GPU(s).
>> 
>>> On 10 Nov. 2016, at 18:35, Tobias Bley <b...@jpro.io> wrote:
>>> 
>>> Do you have started any parallelization?
>>> 
>>> 
>>> 
>>>> Am 10.11.2016 um 01:02 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>>>> 
>>>> If you want to know how to parallelise the JavaFX pipeline (or how it's 
>>>> already been done with amazing results) then talk to me.
>>>> 
>>>> If, of course, this email gets moderated...
>>>> 
>>>>> On 10 Nov. 2016, at 10:57, Felix Bembrick <felix.bembr...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 10 Nov. 2016, at 10:27, Jim Graham <james.gra...@oracle.com> wrote:
>>>>>> 
>>>>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote:
>>>>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single
>>>>>>>> instance) so it is single-threaded.
>>>>>>>> 
>>>>>>>> In MarlinFX I could prepare the multi-threading support by using 1
>>>>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
>>>>>>>> 
>>>>>>>> However it seems a complex task to enable parallelization in the javafx
>>>>>>>> pipeline but I could help there also...
>>>>>>>> 
>>>>>>> 
>>>>>>> Enabling parallel rasterization seems like a good follow-on task, but 
>>>>>>> is out of scope for the short term given the
>>>>>>> limited amount of time. Also, the only way that MarlinFX even has a 
>>>>>>> chance of getting approved for in JDK 9 is for the
>>>>>>> default OpenPisces path to be unaltered.
>>>>>> 
>>>>>> Also, such a parallelization of the javafx pipelines would be a fairly 
>>>>>> large task.
>>>>>> 
>>>>>> I would think an effort to parallelize a single shape rasterization 
>>>>>> would be much simpler in scope.  Still outside the current JDK 9 
>>>>>> timeline, but definitely something that could help in future releases.  
>>>>>> I believe that once we put the edges into the internal structures we 
>>>>>> could parallelize the rasterization of individual scanlines and maybe 
>>>>>> break a tall shape up into N horizontal bands for N threads.  Other 
>>>>>> thoughts would be a thread to generate the crossings and N threads to 
>>>>>> populate the alphas...?
>>>>>> 
>>>>>>   ...jim
>>> 
> 

Re: Marlin-Renderer and JavaFX

[Felix Bembrick]

Started? I have a fully working prototype!

And it's not just "parallelised" but it greatly improves the efficiency and 
utilisation of both the CPU (and cores) and the GPU(s).

> On 10 Nov. 2016, at 18:35, Tobias Bley <b...@jpro.io> wrote:
> 
> Do you have started any parallelization?
> 
> 
> 
>> Am 10.11.2016 um 01:02 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> If you want to know how to parallelise the JavaFX pipeline (or how it's 
>> already been done with amazing results) then talk to me.
>> 
>> If, of course, this email gets moderated...
>> 
>>> On 10 Nov. 2016, at 10:57, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On 10 Nov. 2016, at 10:27, Jim Graham <james.gra...@oracle.com> wrote:
>>>> 
>>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote:
>>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single
>>>>>> instance) so it is single-threaded.
>>>>>> 
>>>>>> In MarlinFX I could prepare the multi-threading support by using 1
>>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
>>>>>> 
>>>>>> However it seems a complex task to enable parallelization in the javafx
>>>>>> pipeline but I could help there also...
>>>>>> 
>>>>> 
>>>>> Enabling parallel rasterization seems like a good follow-on task, but is 
>>>>> out of scope for the short term given the
>>>>> limited amount of time. Also, the only way that MarlinFX even has a 
>>>>> chance of getting approved for in JDK 9 is for the
>>>>> default OpenPisces path to be unaltered.
>>>> 
>>>> Also, such a parallelization of the javafx pipelines would be a fairly 
>>>> large task.
>>>> 
>>>> I would think an effort to parallelize a single shape rasterization would 
>>>> be much simpler in scope.  Still outside the current JDK 9 timeline, but 
>>>> definitely something that could help in future releases.  I believe that 
>>>> once we put the edges into the internal structures we could parallelize 
>>>> the rasterization of individual scanlines and maybe break a tall shape up 
>>>> into N horizontal bands for N threads.  Other thoughts would be a thread 
>>>> to generate the crossings and N threads to populate the alphas...?
>>>> 
>>>> ...jim
> 

Re: Marlin-Renderer and JavaFX

[Felix Bembrick]

> On 10 Nov. 2016, at 10:27, Jim Graham  wrote:
> 
> On 10/20/16 5:34 AM, Kevin Rushforth wrote:
>>> For now the OpenPiscesRasterizer class uses a static Renderer (single
>>> instance) so it is single-threaded.
>>> 
>>> In MarlinFX I could prepare the multi-threading support by using 1
>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
>>> 
>>> However it seems a complex task to enable parallelization in the javafx
>>> pipeline but I could help there also...
>>> 
>> 
>> Enabling parallel rasterization seems like a good follow-on task, but is out 
>> of scope for the short term given the
>> limited amount of time. Also, the only way that MarlinFX even has a chance 
>> of getting approved for in JDK 9 is for the
>> default OpenPisces path to be unaltered.
> 
> Also, such a parallelization of the javafx pipelines would be a fairly large 
> task.
> 
> I would think an effort to parallelize a single shape rasterization would be 
> much simpler in scope.  Still outside the current JDK 9 timeline, but 
> definitely something that could help in future releases.  I believe that once 
> we put the edges into the internal structures we could parallelize the 
> rasterization of individual scanlines and maybe break a tall shape up into N 
> horizontal bands for N threads.  Other thoughts would be a thread to generate 
> the crossings and N threads to populate the alphas...?
> 
>...jim

Re: Marlin-Renderer and JavaFX

[Felix Bembrick]

If you want to know how to parallelise the JavaFX pipeline (or how it's already 
been done with amazing results) then talk to me.

If, of course, this email gets moderated...

> On 10 Nov. 2016, at 10:57, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> 
> 
>> On 10 Nov. 2016, at 10:27, Jim Graham <james.gra...@oracle.com> wrote:
>> 
>> On 10/20/16 5:34 AM, Kevin Rushforth wrote:
>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single
>>>> instance) so it is single-threaded.
>>>> 
>>>> In MarlinFX I could prepare the multi-threading support by using 1
>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
>>>> 
>>>> However it seems a complex task to enable parallelization in the javafx
>>>> pipeline but I could help there also...
>>>> 
>>> 
>>> Enabling parallel rasterization seems like a good follow-on task, but is 
>>> out of scope for the short term given the
>>> limited amount of time. Also, the only way that MarlinFX even has a chance 
>>> of getting approved for in JDK 9 is for the
>>> default OpenPisces path to be unaltered.
>> 
>> Also, such a parallelization of the javafx pipelines would be a fairly large 
>> task.
>> 
>> I would think an effort to parallelize a single shape rasterization would be 
>> much simpler in scope.  Still outside the current JDK 9 timeline, but 
>> definitely something that could help in future releases.  I believe that 
>> once we put the edges into the internal structures we could parallelize the 
>> rasterization of individual scanlines and maybe break a tall shape up into N 
>> horizontal bands for N threads.  Other thoughts would be a thread to 
>> generate the crossings and N threads to populate the alphas...?
>> 
>>   ...jim

Re: Exception running FXMark with JavaFX 9

[Felix Bembrick]

Ah, thanks Vadim.

That would certainly explain the exception!

Cheers,

Felix

> On 17 Aug 2016, at 22:45, Vadim Pakhnushev <vadim.pakhnus...@oracle.com> 
> wrote:
> 
> Felix,
> 
> The com.sun.javafx.perf.PerformanceTracker is in the javafx.graphics module.
> 
> Vadim
> 
>> On 17.08.2016 10:50, Felix Bembrick wrote:
>> OK, I have read the article and followed Rahman's advice (thanks!) and here
>> are my VM args now:
>> 
>> -Djavafx.animation.fullspeed=true
>> -addmods ALL-DEFAULT,java.se.ee
>> -XaddExports:javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED
>> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED
>> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED
>> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED
>> -XaddExports:javafx.base/com.sun.javafx.perf=ALL-UNNAMED
>> 
>> But, when I run FXMark I now get this error:
>> 
>> Error occurred during initialization of VM
>> java.lang.IllegalArgumentException: package com.sun.javafx.perf not in
>> contents
>>  at java.lang.reflect.Module.implAddExports(java.base@9-ea/Module.java:591)
>>  at java.lang.reflect.Module.access$400(java.base@9-ea/Module.java:86)
>>  at java.lang.reflect.Module$1.addExportsToAllUnnamed(java.base@9-ea
>> /Module.java:1109)
>>  at jdk.internal.module.Modules.addExportsToAllUnnamed(java.base@9-ea
>> /Modules.java:124)
>>  at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base@9-ea
>> /ModuleBootstrap.java:476)
>>  at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea
>> /ModuleBootstrap.java:322)
>>  at java.lang.System.initPhase2(java.base@9-ea/System.java:1930)
>> 
>> Can anyone point out what I am doing wrong?
>> 
>> Cheers,
>> 
>> Felix
>> 
>> 
>>> On 17 August 2016 at 00:22, Rahman USTA <rahman.usta...@gmail.com> wrote:
>>> 
>>> Dear Felix;
>>> 
>>> I'm running AsciidocFX with the following JVM parameters. They can help
>>> you.
>>> 
>>> -Djava.awt.headless=false
>>> -XaddExports:javafx.graphics/
>>> com.sun.javafx.stage=ALL-UNNAMED -addmods ALL-DEFAULT,java.se.ee
>>> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>>> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED
>>> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED
>>> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED
>>> -addmods javafx.deploy,ALL-SYSTEM
>>> 
>>> I thought that the followings may help you
>>> 
>>> -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.base/com.
>>> sun.javafx.perf=ALL-UNNAMED
>>> 
>>> Thanks.
>>> 
>>> 2016-08-16 8:50 GMT+03:00 Felix Bembrick <felix.bembr...@gmail.com>:
>>> 
>>>> I am trying to port FXMark from Java 8 to Java 9 but encounter this
>>>> exception:
>>>> 
>>>> Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in
>>>> unnamed module @0x59223fd5) cannot access class
>>>> com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics)
>>>> because
>>>> module javafx.graphics does not export com.sun.javafx.perf to unnamed
>>>> module @0x59223fd5
>>>> 
>>>> How do I access PerformanceTracker in Java/JavaFX 9?
>>>> 
>>>> Thanks,
>>>> 
>>>> Felix
>>> 
>>> 
>>> --
>>> Rahman USTA
>>> Istanbul JUG
>>> https://github.com/rahmanusta <http://www.kodcu.com/>
> 

Re: Exception running FXMark with JavaFX 9

[Felix Bembrick]

OK, I have read the article and followed Rahman's advice (thanks!) and here
are my VM args now:

-Djavafx.animation.fullspeed=true
-addmods ALL-DEFAULT,java.se.ee
-XaddExports:javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED
-XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED
-XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED
-XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED
-XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED
-XaddExports:javafx.base/com.sun.javafx.perf=ALL-UNNAMED

But, when I run FXMark I now get this error:

Error occurred during initialization of VM
java.lang.IllegalArgumentException: package com.sun.javafx.perf not in
contents
 at java.lang.reflect.Module.implAddExports(java.base@9-ea/Module.java:591)
 at java.lang.reflect.Module.access$400(java.base@9-ea/Module.java:86)
 at java.lang.reflect.Module$1.addExportsToAllUnnamed(java.base@9-ea
/Module.java:1109)
 at jdk.internal.module.Modules.addExportsToAllUnnamed(java.base@9-ea
/Modules.java:124)
 at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base@9-ea
/ModuleBootstrap.java:476)
 at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea
/ModuleBootstrap.java:322)
 at java.lang.System.initPhase2(java.base@9-ea/System.java:1930)

Can anyone point out what I am doing wrong?

Cheers,

Felix


On 17 August 2016 at 00:22, Rahman USTA <rahman.usta...@gmail.com> wrote:

> Dear Felix;
>
> I'm running AsciidocFX with the following JVM parameters. They can help
> you.
>
> -Djava.awt.headless=false
> -XaddExports:javafx.graphics/
> com.sun.javafx.stage=ALL-UNNAMED -addmods ALL-DEFAULT,java.se.ee
> -XaddExports:javafx.base/com.sun.javafx.collections=ALL-UNNAMED
> -XaddExports:javafx.base/com.sun.javafx.property=ALL-UNNAMED
> -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED
> -XaddExports:javafx.base/com.sun.javafx.event=ALL-UNNAMED
> -addmods javafx.deploy,ALL-SYSTEM
>
> I thought that the followings may help you
>
> -addmods ALL-DEFAULT,java.se.ee -XaddExports:javafx.base/com.
> sun.javafx.perf=ALL-UNNAMED
>
> Thanks.
>
> 2016-08-16 8:50 GMT+03:00 Felix Bembrick <felix.bembr...@gmail.com>:
>
>> I am trying to port FXMark from Java 8 to Java 9 but encounter this
>> exception:
>>
>> Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in
>> unnamed module @0x59223fd5) cannot access class
>> com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics)
>> because
>> module javafx.graphics does not export com.sun.javafx.perf to unnamed
>> module @0x59223fd5
>>
>> How do I access PerformanceTracker in Java/JavaFX 9?
>>
>> Thanks,
>>
>> Felix
>>
>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>
>

Exception running FXMark with JavaFX 9

[Felix Bembrick]

I am trying to port FXMark from Java 8 to Java 9 but encounter this
exception:

Caused by: java.lang.IllegalAccessError: class com.bembrick.fxmark.HUD (in
unnamed module @0x59223fd5) cannot access class
com.sun.javafx.perf.PerformanceTracker (in module javafx.graphics) because
module javafx.graphics does not export com.sun.javafx.perf to unnamed
module @0x59223fd5

How do I access PerformanceTracker in Java/JavaFX 9?

Thanks,

Felix

Re: Scene graph performance

[Felix Bembrick]

Sorry, take 2.

Thanks - that's very helpful.

I have been concentrating on profiling the Java aspects of FXMark so this gives 
me more things to try.

I will report back with my findings.

Blessings,

Felix

> On 22 Jul 2016, at 19:02, Vadim Pakhnushev <vadim.pakhnus...@oracle.com> 
> wrote:
> 
>> On 22.07.2016 11:15, Felix Bembrick wrote:
>> Hi Vadim,
>> 
>> I am very open-minded about this. Anything is possible (including, as I 
>> mentioned, that I wrote FXMark very poorly).
>> 
>> Can you help by detailing what tools you use to track CPU/GPU usage?
> 
> I personally use Process Hacker (I'm on Windows) and it's sitting in my tray 
> all the time so I can see exactly what's happening.
> Process Explorer is another very popular task manager replacement with 
> similar features.
> It can show you overall system load as well as individual process's 
> performance graphs including GPU load.
> 
> Vadim

Re: Scene graph performance

[Felix Bembrick]

> On 22 Jul 2016, at 19:02, Vadim Pakhnushev <vadim.pakhnus...@oracle.com> 
> wrote:
> 
>> On 22.07.2016 11:15, Felix Bembrick wrote:
>> Hi Vadim,
>> 
>> I am very open-minded about this. Anything is possible (including, as I 
>> mentioned, that I wrote FXMark very poorly).
>> 
>> Can you help by detailing what tools you use to track CPU/GPU usage?
> 
> I personally use Process Hacker (I'm on Windows) and it's sitting in my tray 
> all the time so I can see exactly what's happening.
> Process Explorer is another very popular task manager replacement with 
> similar features.
> It can show you overall system load as well as individual process's 
> performance graphs including GPU load.
> 
> Vadim

Re: Scene graph performance

[Felix Bembrick]

Hi Vadim,

I am very open-minded about this. Anything is possible (including, as I 
mentioned, that I wrote FXMark very poorly).

Can you help by detailing what tools you use to track CPU/GPU usage?

I am sure finding out the exact nature of what is happening and what is causing 
it will help everyone.

And, quite frankly, I actually hope that my coding *is* the problem and not 
JavaFX.

Why? 

Because I can fix my coding.

Blessings,

Felix

> On 22 Jul 2016, at 17:56, Vadim Pakhnushev <vadim.pakhnus...@oracle.com> 
> wrote:
> 
> Felix,
> 
> For me it's very useful to track CPU/GPU usage while running a benchmark.
> Could it be that your very fast machine is limited by some synchronization 
> issues and CPU/GPU is essentially idle while slower machine is running 100% 
> CPU?
> 
> Vadim
> 
>> On 22.07.2016 3:35, Felix Bembrick wrote:
>> I am willing to accept that perhaps FXMark is written so poorly that it
>> does not permit JavaFX to perform as well as it could (possibly
>> significantly so) on any particular platform.
>> 
>> 
> 

Re: Scene graph performance

[Felix Bembrick]

I am willing to accept that perhaps FXMark is written so poorly that it
does not permit JavaFX to perform as well as it could (possibly
significantly so) on any particular platform.

And I am indeed going through the code line-by-line and doing all manner of
profiling to try to answer this question.

But ultimately, the actual scene graph animations are *very* simple in
structure. They simply comprise a number of nodes with parallel transitions
built up from those selected in the list and the effects selected are
applied to each node.

It's basically just using transitions and effects exactly as documented and
in the simplest way possible.

Now, perhaps there are "other" less obvious ways of constructing parallel
transitions and applying effects or special tweaks that I am not aware of.
Perhaps there are ways of optimising the performance in a number of ways
that I am not aware of.

But, I have researched these issues on StackOverflow etc. (in fact the
whole interwebs) and I have yet to find anything which I am obviously doing
very wrongly or anything which can even marginally improve the performance
(and by performance I refer to FPS and a visual interpretation of
"smoothness").

Now the latter of those metrics is clearly not at all scientific, but FPS
is very scientific. But, maybe it's a case that JavaFX *could* render at a
faster frame rate but simply *doesn't need to* (as 60 FPS is really ample
for most scenarios).

However, when you apply certain transitions (especially rotation for
example) and certain effects (especially Glow or Bloom), the entire
animation of even just 25 nodes can literally "grind to a halt".

Does that matter? Well, I guess it matters to some and not to others.  Like
most things.

I guess my overriding concern is that it's not so much that the frame rate
shows little "improvement" on my beast of a machine, but also that those
especially slow transitions and effects show little or no improvement
either.

So, if for example, you wanted to build a game with JavaFX, you cannot use
the scene graph and utilise nodes for every "entity" in the game and expect
to get high performance "action".  Your only realistic option is to write a
2D (or pseudo-3D) game using Canvas because the Canvas node performance is
quite good.

Which of course could raise the question, why even *have* a scene graph in
JavaFX?

When JavaFX was first "conceived", a different approach could have been to
simply add the key missing components to Swing such as media and a decent
browser control and improve the GPU utlisation of what was already an
immediate mode (and hardware accelerated) toolkit (ala Canvas) and you
would have much more quickly had effectively what we have right now: a
toolkit primarily aimed at building business/forms applications (not games
or advanced visualisations) with a few "fancy/sexy" bits thrown in, BUT you
would also have a vastly larger collection of highly customisable controls
that have stood the test of time and there would also be almost no learning
curve.

So, yes it's a different topic and a different thread and it may not be one
that people want to discuss, but I would like to pose the question at some
point: "What advantages does the scene graph give JavaFX over the immediate
mode rendering of Swing?".  Well, I guess one obvious thing is a
declarative representation such a FXML but, then again, there have been a
number of GUI builders for Swing for many years that basically do something
very similar (only it's "optional").

At the moment, it's almost as though the scene graph is more of a hindrance
(at least in terms of rendering performance) than a benefit.

I personally would love to see the JavaFX scene graph be able to work just
as OpenSceneGraph or the way scene graphs of advanced game engines work
with greatly improved performance over what we have now.

That however seems to be at least 4 years away from ever happening...

Felix



On 22 July 2016 at 08:51, Hervé Girod <herve.gi...@gmail.com> wrote:

> We use a lot of Nodes which we update dynamically from another Client App.
> We also use JavaFX animations, but admittedly not a lot of them
> concurrently.
>
> In our case JavaFX animations are mainly linked to user interactions, a
> lot of what is dynamic in our apps is directly a result of real data
> changing in real time (such as track positions or plane attitude for
> example).
>
> But these changes can update a lot of Nodes concurrently, and not always
> simply by translating a parent container. For example if you have a digital
> Map with a lot of real world content (flight plan, waypoints, tracks,
> etc...), and the reference of the Map is the aircraft, you can't just move
> the whole map when the position of the aircraft changes, because you have
> to compute the coordinates of each element in the projection sy

Re: Scene graph performance

[Felix Bembrick]

I agree that the original question has led to a discussion of a somewhat 
different nature and I accept that the benchmark itself may be problematic.

But others have reported similar observation using different benchmarks.

> On 22 Jul 2016, at 07:42, Steve Hannah <st...@weblite.ca> wrote:
> 
> I've just been a fly on the wall for this thread, but ... I think this
> thread has gone off track a bit.  Felix's original observation was that he
> got the same benchmark results from two machines that should produce
> different results because one is more powerful than the other in both CPU
> and GPU).  The talk of things that could be done to improve JavaFX
> performance don't seem relevant to this.  The real question is, why is a
> slow computer performing as well as a fast computer?
> 
> The answer is likely far simpler than the explanations proposed here.
> Either there is a problem with the benchmark methodology, there is an
> environment difference that isn't being accounted for (which is also a
> methodology problem), or there is some mechanism that is throttling
> performance.
> 
> My hunch is that there is a problem with the benchmark.
> 
> Steve
> 
>> On Thu, Jul 21, 2016 at 2:33 PM, Hervé Girod <herve.gi...@gmail.com> wrote:
>> 
>> I really don't understand all this. We use Java FX 8 in a graphic
>> framework where we need high performance (prototyping Cockpit Display
>> Systems with dynamic Maps and Head Up Displays), and we find that JavaFX
>> performance is pretty good our use case. For example, Qt / QML performance
>> is far worse in our POV, for no real additional simplicity of usage for big
>> projects. We also used OpenGL before (used JOGL), but (at least for our own
>> usage) what additional performance benefits we could maybe achieve were not
>> worth the amount of work we would have needed to get them (if we had any).
>> 
>> Hervé
>> 
>> Sent from my iPad
>> 
>>>> On 21 juil. 2016, at 23:09, Felix Bembrick <felix.bembr...@gmail.com>
>>> wrote:
>>> 
>>> Yes, well I think this the problem:
>>> 
>>> 1) Going on history, it would be a best case scenario for Java 10 to be
>> released in 2020 (but more likely 2021).
>>> 
>>> 2) With JavaFX, we are already "behind the game" (pun intended).
>>> 
>>> 3) JavaFX itself has evolved much slower than its competitors.
>>> 
>>> 4) Technology in general will have moved ahead by massive leaps by 2021
>> (including our competitors).
>>> 
>>> 5) If the *first* optimised JavaFX scene graph is not released until
>> 2021, I genuinely fear that not only would "the ship have sailed" but, it
>> would actually be way over the horizon and completely out of sight.
>>> 
>>> Felix
>>> 
>>>> On 22 Jul 2016, at 06:51, dalibor topic <dalibor.to...@oracle.com>
>> wrote:
>>>> 
>>>> There is no JDK 10 Project in OpenJDK yet, so there has been no
>> proposed schedule for it yet.
>>>> 
>>>> cheers,
>>>> dalibor topic
>>>> 
>>>>> On 21.07.2016 20:51, Felix Bembrick wrote:
>>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if
>> possible) for the the release date for JDK 10?
>>>>> 
>>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth <kevin.rushfo...@oracle.com>
>> wrote:
>>>>>> 
>>>>>> Oh, I was agreeing with the analysis of what *would* need to be done.
>> I am not saying that I think it *should* be done, given resources other
>> priorities, etc. Having said that, as I mentioned in an earlier post a
>> month or so ago, we will be collecting ideas for possible JDK 10 features
>> once JDK 9 is finished. Perhaps this could go into the bucket of things to
>> consider, but it isn't something I would think would be high on the
>> listcompared to, say, WebGL, some sort of interop with native
>> rendering, updated graphics pipelines (we're current stuck on DX 9 and GL
>> 2), public API for UI Controls Behaviors, etc.
>>>>>> 
>>>>>> -- Kevin
>>>>>> 
>>>>>> 
>>>>>> Felix Bembrick wrote:
>>>>>>> Well, I'm putting my hand up for this.
>>>>>>> 
>>>>>>> Kevin, would you like to discuss this with me on or offline?
>>>>>>> 
>>>>>>> Felix
>>>>>>> 
>>>>>>> P.S. Thanks Markus for your insight!
>>>>>>> 
>>>>>>> 
>>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Yep.
> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.

Re: Scene graph performance

[Felix Bembrick]

Are you using nodes, transitions, effects and animations? Or are you using the 
Canvas node only?

> On 22 Jul 2016, at 07:33, Hervé Girod <herve.gi...@gmail.com> wrote:
> 
> I really don't understand all this. We use Java FX 8 in a graphic framework 
> where we need high performance (prototyping Cockpit Display Systems with 
> dynamic Maps and Head Up Displays), and we find that JavaFX performance is 
> pretty good our use case. For example, Qt / QML performance is far worse in 
> our POV, for no real additional simplicity of usage for big projects. We also 
> used OpenGL before (used JOGL), but (at least for our own usage) what 
> additional performance benefits we could maybe achieve were not worth the 
> amount of work we would have needed to get them (if we had any). 
> 
> Hervé
> 
> Sent from my iPad
> 
>> On 21 juil. 2016, at 23:09, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> 
>> Yes, well I think this the problem:
>> 
>> 1) Going on history, it would be a best case scenario for Java 10 to be 
>> released in 2020 (but more likely 2021).
>> 
>> 2) With JavaFX, we are already "behind the game" (pun intended).
>> 
>> 3) JavaFX itself has evolved much slower than its competitors.
>> 
>> 4) Technology in general will have moved ahead by massive leaps by 2021 
>> (including our competitors).
>> 
>> 5) If the *first* optimised JavaFX scene graph is not released until 2021, I 
>> genuinely fear that not only would "the ship have sailed" but, it would 
>> actually be way over the horizon and completely out of sight.
>> 
>> Felix
>> 
>>> On 22 Jul 2016, at 06:51, dalibor topic <dalibor.to...@oracle.com> wrote:
>>> 
>>> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed 
>>> schedule for it yet.
>>> 
>>> cheers,
>>> dalibor topic
>>> 
>>>> On 21.07.2016 20:51, Felix Bembrick wrote:
>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity if 
>>>> possible) for the the release date for JDK 10?
>>>> 
>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> Oh, I was agreeing with the analysis of what *would* need to be done. I 
>>>>> am not saying that I think it *should* be done, given resources other 
>>>>> priorities, etc. Having said that, as I mentioned in an earlier post a 
>>>>> month or so ago, we will be collecting ideas for possible JDK 10 features 
>>>>> once JDK 9 is finished. Perhaps this could go into the bucket of things 
>>>>> to consider, but it isn't something I would think would be high on the 
>>>>> listcompared to, say, WebGL, some sort of interop with native 
>>>>> rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 
>>>>> 2), public API for UI Controls Behaviors, etc.
>>>>> 
>>>>> -- Kevin
>>>>> 
>>>>> 
>>>>> Felix Bembrick wrote:
>>>>>> Well, I'm putting my hand up for this.
>>>>>> 
>>>>>> Kevin, would you like to discuss this with me on or offline?
>>>>>> 
>>>>>> Felix
>>>>>> 
>>>>>> P.S. Thanks Markus for your insight!
>>>>>> 
>>>>>> 
>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Yep.

Re: Scene graph performance

[Felix Bembrick]

Well, I'm putting my hand up for this.

Kevin, would you like to discuss this with me on or offline?

Felix

P.S. Thanks Markus for your insight!

> On 22 Jul 2016, at 04:22, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
> 
> Yep.
> 
> -- Kevin
> 
> 
> Richard Bair wrote:
>> I think you just nailed it on the head Markus :-).
>> 
>>  
>>> On Jul 21, 2016, at 10:56 AM, Markus KARG <mar...@headcrashing.eu> wrote:
>>> 
>>> 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 
>>>> 

Re: Scene graph performance

[Felix Bembrick]

I would add that neither JOGL nor LWJGL have these issues.

Yes, I know they are somewhat different "animals", but the point is, clearly 
*Java* is NOT the cause.

> On 21 Jul 2016, at 20:07, Dr. Michael Paus <m...@jugs.org> wrote:
> 
> 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: Scene graph performance

[Felix Bembrick]

Hi Michael,

Thanks for your response.

This is what I suspected: what is ostensibly a hardware accelerated toolkit 
seems to barely utilise the GPU for scene graph animations.

But, even with that, my machine has dual high performance 16-core Xeons while 
my wife's machine has a single 2-core i5 and STILL the performance is barely 
indistinguishable!

I would love to discuss this with you off-list as I see this as the biggest 
impediment to expanding the use cases for JavaFX.

The Canvas node seems to perform quite well but, other than that, we basically 
have a toolkit suitable for forms with the occasional transition thrown in.

I think I can fix these issues and I will continue to further investigate the 
cause.

It's somewhat ridiculous that on my same machine I can write pure OpenGL code 
(not Direct3D) and animate 5000 Quake 3D characters and achieve at least 1000 
FPS.

I don't think we can blame Java the language as Java is not running on the GPU. 

It appears though that not much else is either!

(It seems the Quantum Renderer thread is working really, really hard. The GPU 
should be doing most of the heavy lifting).

Felix

> On 21 Jul 2016, at 20:07, Dr. Michael Paus <m...@jugs.org> wrote:
> 
> 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
> 
> 

Looking forward to JavaFX 9!

[Felix Bembrick]

OK, I have learned my lesson - I will be careful to be strictly on-topic and 
very well behaved in this post.

So, I would simply request if someone could please provide a complete list of 
all the NEW features that are either planned or possibly going to be included 
in JavaFX 9.

Being totally committed to this awesome toolkit, it's obvious that I am 
extremely excited about all the amazing new features that ISVs like us will 
soon be able to use to produce world class software! I can't wait!

Obviously, WebGL is a given as are programmable shaders and they will most 
certainly be very valuable. Naturally TableView will be completely rewritten, a 
3D Canvas is a must and it goes without saying that the rendering pipeline will 
also be totally scrapped and rebuilt to use the GPU and actually be made 
performant enough to move more than 2 or 3 nodes around the screen at once.

I am even clinging on to the slim hope that my lifelong goal of writing a 
modern version of Pong (which I will call Smell) will finally be possible with 
JavaFX.

Clearly JavaFX 9 will "just work" out of the box on iOS, Android and VIC 20.

I am sure I don't even need to mention the features everyone is already aware 
of like  official high performance versions for embedded devices and the IoT.

Obviously a game engine will be included along with an advanced physics engine 
and built-in support for monetisation on all those mobile platforms it will run 
on.

And It goes without saying that not every method in every class will be marked 
final (finally).

The features I am looking forward to the most though are of course the JavaFX 
Asset Store, the animation editor and, especially the highly anticipated JavaFX 
Watch.

But other than these features which most people already know about, what are 
all the other new exciting features?

I know everyone is busy so how about you just rank the top 100 and we can do 
our homework to identify the 500 or so..

Anyway, congratulations to Oracle executives for really getting behind their 
flagship product and investing the millions of dollars it has taken to make 
such awesome features possible.

I am sure I speak on behalf of the entire JavaFX community in thanking you all 
for this devotion and enthusiasm and I want you to know just how incredibly 
excited we all are about this extremely significant next release and its 
ability to change the world of software forever!

Humbly and sincerely,

Felix

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Mario, I would really love to agree with you but then sadly we'd both be wrong.

But thanks for not sending this email just to me "offline" for a change (and 
for being far more polite)...

> On 14 Jun 2016, at 21:05, Mario Torre  wrote:
> 
> On Tue, Jun 14, 2016 at 12:25 PM, Robert Krüger
>  wrote:
>> Only regarding the net loss for the community: There are not many places
>> where people trying to defend (and make a living off) Java as a viable
>> desktop technology can try to get information from Oracle and the questions
>> he asks are also the ones we (as an ISV with a Java-based product) would
>> ask, so I do regard them as valuable.
>> 
>> Having said that, I understand, however that those things will never get an
>> answer here (never have in the past, having asked such questions myself).
>> 
>> Just writing that so Felix does not feel that he's alone with his concerns
>> and to add another data point on the Oracle radar that Houston, we do have
>> a real problem here and quite a few frustrated Java advocates.
> 
> Eh, I thought this thread was finally over...
> 
> This mailing list is definitely not the place to discuss such things.
> 
> Discussing Oracle plans is something only Oracle can do, so asking
> about those on a development mailing lists doesn't work out.
> 
> As for more general things, even including adoption of the technology,
> that may be more or less related to actual development, there are
> other, better, places, for example FOSDEM and JavaOne are just two of
> the various conferences that generated great and very useful deal of
> discussions over the years.
> 
> If you care about participating in a constructive manner, you should
> check those out, really. There are other channels, too. For instance,
> the Adoption Group is a great place to start asking questions. No, not
> questions like what Oracle is planning to do with XXX, you won't find
> answer for those there, but you'll be directed in how to contribute,
> and contribution means also discussing in a constructive manner (this
> can also have the form harsh criticism at times, btw, as long as is
> not gratuitous).
> 
> That said, it has happened in the past, and will certainly happen in
> the future, that some questions that touch areas perhaps less round
> regarding the actual development like interest is specific means of
> integrations or specific issues about adoption, etc... find a place of
> discussion here. This is not how generally works, because this is
> about development, but it's understandable in a living Community to
> also take *some* discussion at that level.
> 
> The problem here is another one. First, insisting when somebody have
> been asked, politely, to stop, and the second and most important is
> the manner of presenting ones idea, by hijacking a purely development
> oriented thread with random and totally unclear questions, attempted
> sarcasm and just lots of negativity. A thread, btw, that asked the
> Community suggestions how to proceed regarding the removal of rather
> unused code, so instead of having a constructive participation in a
> technically oriented thread, the thread was hijacked with harsh
> resentment both on and especially off-list resulting in just a missed
> opportunity if you ask me.
> 
> Just to conclude, there are just too many layers before our voices can
> be heard by who makes decision, if we start off by screaming chances
> are that our messages will never go through, instead ranting and
> offending only has the effect of lowering ones credibility, so if you
> fall on this side, even with the best intentions, your "contributions"
> will likely end up nowhere.
> 
> Please, let's try to be constructive, there is a place and a time for
> everything.
> 
> Cheers,
> Mario
> 
> -- 
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> 
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> 
> Please, support open standards:
> http://endsoftpatents.org/

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Thanks Robert - much appreciated.

Just be careful, you may soon be labelled a spammer, get threatened with being 
banned from this list and also expect random creeps to send you private 
(cowardly) "offline" insults.

But, don't worry, I am well aware of the *massive* number of poor believers in 
JavaFX out there who can get nothing but intimidation out of Oracle.

I am just the one who put my hand up to say what everyone else is thinking 
simply because their lame efforts to "dispose" of me just make me chuckle...

P.S. I am willing to bet this post will "magically" not make it into the list 
somehow...

But you will at least get it.

So much for "open" JFX!

Blessings,

Felix

> On 14 Jun 2016, at 20:25, Robert Krüger <krueger@lesspain.software> wrote:
> 
> Only regarding the net loss for the community: There are not many places 
> where people trying to defend (and make a living off) Java as a viable 
> desktop technology can try to get information from Oracle and the questions 
> he asks are also the ones we (as an ISV with a Java-based product) would ask, 
> so I do regard them as valuable.
> 
> Having said that, I understand, however that those things will never get an 
> answer here (never have in the past, having asked such questions myself).
> 
> Just writing that so Felix does not feel that he's alone with his concerns 
> and to add another data point on the Oracle radar that Houston, we do have a 
> real problem here and quite a few frustrated Java advocates.
> 
> Over and out.
> 
> Robert
> 
>> On Mon, Jun 13, 2016 at 4:26 PM, dalibor topic <dalibor.to...@oracle.com> 
>> wrote:
>>> On 13.06.2016 15:02, Felix Bembrick wrote:
>>> I am one of the most vocal, passionate and positive advocates for OpenJFX 
>>> and JavaFX.
>> 
>> Felix,
>> 
>> That may very well be the case, in your opinion, but this mailing list is 
>> not a forum for advocacy. It is for technical discussions.
>> 
>> Whether you are or you are not an advocate for something or other is not 
>> relevant on this mailing list. Maybe there is some other forum where people 
>> who are advocates for things meet and have vocal and passionate discussions 
>> with each other. In any case, this mailing list is not it, because what you 
>> are or what you aren't is not a technical subject to begin with.
>> 
>> Unless you are a robot, of course. But in that case, this mailing list would 
>> still be the wrong forum ...
>> 
>> Please, hold off on posting off-topic posts to this list for a week or two.
>> 
>> If for some reason you feel the need to continue to spam this mailing list 
>> with off-topic posts, as you have done so far, despite being asked to stop 
>> both on and off-list, then I trust that the mailing list administrator could 
>> take care of this problem for all of us.
>> 
>> cheers,
>> dalibor topic
>> 
>> 
>>>> On 13 Jun 2016, at 22:45, dalibor topic <dalibor.to...@oracle.com> wrote:
>>>> 
>>>> Felix,
>>>> 
>>>> This is an open source Project's mailing list, specifically for technical 
>>>> discussions of that Project's development. It's not an 'open' forum 
>>>> suitable for discussion of other issues.
>>>> 
>>>> Removing participants that continue to abuse the privilege of being on an 
>>>> open source project's mailing list is a useful tool to deal with 
>>>> individuals which contribute negatively to a project, if they don't seem 
>>>> to be able to change their act.
>>>> 
>>>> cheers,
>>>> dalibor topic
>>>> 
>>>>> On 13.06.2016 14:11, Felix Bembrick wrote:
>>>>> Dear Dalibor,
>>>>> 
>>>>> "This mailing list is the not the right forum for discussions of
>>>>> Oracle's products. This mailing list is for OpenJFX development,
>>>>> specifically."
>>>>> 
>>>>> Read that again. Thank you for giving me the clear answer you promised!
>>>>> 
>>>>> And thanks for the warning in case I accidentally start "spamming". But
>>>>> surely you wouldn't remove anyone from an "open" forum would you?
>>>>> 
>>>>> Blessings,
>>>>> 
>>>>> Felix
>>>>> 
>>>>> On 13 Jun 2016, at 21:17, dalibor topic <dalibor.to...@oracle.com
>>>>> <mailto:dalibor.to...@oracle.com>> wrote:
>>>>> 
>>>>>> Felix,
>>>&

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Are you saying that I have negatively contributed to OpenJFX or JavaFX in 
general?

I am one of the most vocal, passionate and positive advocates for OpenJFX and 
JavaFX.

> On 13 Jun 2016, at 22:45, dalibor topic <dalibor.to...@oracle.com> wrote:
> 
> Felix,
> 
> This is an open source Project's mailing list, specifically for technical 
> discussions of that Project's development. It's not an 'open' forum suitable 
> for discussion of other issues.
> 
> Removing participants that continue to abuse the privilege of being on an 
> open source project's mailing list is a useful tool to deal with individuals 
> which contribute negatively to a project, if they don't seem to be able to 
> change their act.
> 
> cheers,
> dalibor topic
> 
>> On 13.06.2016 14:11, Felix Bembrick wrote:
>> Dear Dalibor,
>> 
>> "This mailing list is the not the right forum for discussions of
>> Oracle's products. This mailing list is for OpenJFX development,
>> specifically."
>> 
>> Read that again. Thank you for giving me the clear answer you promised!
>> 
>> And thanks for the warning in case I accidentally start "spamming". But
>> surely you wouldn't remove anyone from an "open" forum would you?
>> 
>> Blessings,
>> 
>> Felix
>> 
>> On 13 Jun 2016, at 21:17, dalibor topic <dalibor.to...@oracle.com
>> <mailto:dalibor.to...@oracle.com>> wrote:
>> 
>>> Felix,
>>> 
>>> if you'd like to ask questions about Oracle's products, please do so
>>> at https://community.oracle.com/welcome .
>>> 
>>> This mailing list is the not the right forum for discussions of
>>> Oracle's products. This mailing list is for OpenJFX development,
>>> specifically.
>>> 
>>> On a side note, spamming this list with off-topic posts could result
>>> in removal from it without further warning.
>>> 
>>> cheers,
>>> dalibor topic
>>> 
>>>> On 13.06.2016 12:37, Felix Bembrick wrote:
>>>> Thanks you most sincerely Dalibor for that very direct response.
>>>> 
>>>> Only... it wasn't really, was it?
>>>> 
>>>> You "believe I am entitled to a clear answer to my question".
>>>> 
>>>> Great! */So why have you still not answered it?/*
>>>> 
>>>> Let me put it another way */so as there can be no possible room for any
>>>> further confusion (hopefully)/*.
>>>> 
>>>> */COULD YOU PLEASE DETAIL EXACTLY WHERE JAVAFX IS USED IN EITHER
>>>> PRODUCTS USED INTERNALLY BY ORACLE OR IN COMMERCIAL PRODUCTS WHICH
>>>> ORACLE MARKETS?/*
>>>> 
>>>> Now, please give me the "clear answer" that I "am entitled to" (Your
>>>> words, not mine).
>>>> 
>>>> (Given that we now know that usage of JavaFX within JMX is about to be
>>>> abandoned, and there may be a tiny fraction of JMC that is still gasping
>>>> for air written using JavaFX, but knowing how */incredibly
>>>> enthusiastically Oracle is advancing JavaFX/*, I *know* there must be
>>>> hundreds more examples and I am sure we would all love to hear about
>>>> them).  That would give us all a lot more faith in JavaFX. I am sure you
>>>> want that don't you?
>>>> 
>>>> See - no mention of age of participants, telephony equipment or career
>>>> plans! Just JMX and a lot about OpenJFX!
>>>> 
>>>> Am I *still* in the wrong forum?
>>>> 
>>>> All my blessings,
>>>> 
>>>> Felix
>>>> 
>>>> P.S. What is this "bitterness" that you speak of?
>>>> 
>>>> 
>>>> 
>>>> On 13 June 2016 at 19:55, dalibor topic <dalibor.to...@oracle.com
>>>> <mailto:dalibor.to...@oracle.com>
>>>> <mailto:dalibor.to...@oracle.com>> wrote:
>>>> 
>>>>   Felix, I believe that you are entitled to a clear answer to your
>>>>   question:
>>>> 
>>>>   Yes, I have considered a career in politics.
>>>> 
>>>>   That being said, I would kindly suggest that you stop trying to
>>>>   divert[0] technical discussions in this community with off-topic
>>>>   posts, such as your contributions to this thread so far, where you
>>>>   attempted to discuss :
>>>> 
>>>>* the age of discussion participants,
>>>>* their telephony

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Dear Dalibor,

"This mailing list is the not the right forum for discussions of Oracle's 
products. This mailing list is for OpenJFX development, specifically."

Read that again. Thank you for giving me the clear answer you promised!

And thanks for the warning in case I accidentally start "spamming". But surely 
you wouldn't remove anyone from an "open" forum would you?

Blessings,

Felix

> On 13 Jun 2016, at 21:17, dalibor topic <dalibor.to...@oracle.com> wrote:
> 
> Felix,
> 
> if you'd like to ask questions about Oracle's products, please do so at 
> https://community.oracle.com/welcome .
> 
> This mailing list is the not the right forum for discussions of Oracle's 
> products. This mailing list is for OpenJFX development, specifically.
> 
> On a side note, spamming this list with off-topic posts could result in 
> removal from it without further warning.
> 
> cheers,
> dalibor topic
> 
>> On 13.06.2016 12:37, Felix Bembrick wrote:
>> Thanks you most sincerely Dalibor for that very direct response.
>> 
>> Only... it wasn't really, was it?
>> 
>> You "believe I am entitled to a clear answer to my question".
>> 
>> Great! */So why have you still not answered it?/*
>> 
>> Let me put it another way */so as there can be no possible room for any
>> further confusion (hopefully)/*.
>> 
>> */COULD YOU PLEASE DETAIL EXACTLY WHERE JAVAFX IS USED IN EITHER
>> PRODUCTS USED INTERNALLY BY ORACLE OR IN COMMERCIAL PRODUCTS WHICH
>> ORACLE MARKETS?/*
>> 
>> Now, please give me the "clear answer" that I "am entitled to" (Your
>> words, not mine).
>> 
>> (Given that we now know that usage of JavaFX within JMX is about to be
>> abandoned, and there may be a tiny fraction of JMC that is still gasping
>> for air written using JavaFX, but knowing how */incredibly
>> enthusiastically Oracle is advancing JavaFX/*, I *know* there must be
>> hundreds more examples and I am sure we would all love to hear about
>> them).  That would give us all a lot more faith in JavaFX. I am sure you
>> want that don't you?
>> 
>> See - no mention of age of participants, telephony equipment or career
>> plans! Just JMX and a lot about OpenJFX!
>> 
>> Am I *still* in the wrong forum?
>> 
>> All my blessings,
>> 
>> Felix
>> 
>> P.S. What is this "bitterness" that you speak of?
>> 
>> 
>> 
>> On 13 June 2016 at 19:55, dalibor topic <dalibor.to...@oracle.com
>> <mailto:dalibor.to...@oracle.com>> wrote:
>> 
>>Felix, I believe that you are entitled to a clear answer to your
>>question:
>> 
>>Yes, I have considered a career in politics.
>> 
>>That being said, I would kindly suggest that you stop trying to
>>divert[0] technical discussions in this community with off-topic
>>posts, such as your contributions to this thread so far, where you
>>attempted to discuss :
>> 
>> * the age of discussion participants,
>> * their telephony equipment and
>> * career plans,
>> 
>>none of which have anything to do with JMX or OpenJFX.
>> 
>>Instead, you should consider unsubscribing from this mailing list
>>for a week or two, in order to get clarity in what capacity, if any,
>>you'd like to positively contribute to ongoing OpenJFX development.
>> 
>>As it stands, your current mode of participation on this mailing
>>list is a net loss for this community, and apparently, for yourself
>>as well, judging by what seems to be an increasing amount of
>>bitterness in your posts.
>> 
>>You can change that.
>> 
>>All the best,
>>Dalibor Topic
>> 
>>[0] https://joeyh.name/blog/entry/thread_patterns/
>> 
>> 
>>On 10.06.2016 15:29, Felix Bembrick wrote:
>> 
>>Dalibor, please forgive me for assuming that Oracle had access
>>to an English language parser. I could translate my original
>>question into Klingon and resubmit if that would help.
>> 
>>And thanks so much for pointing out to me that this forum is
>>devoted to "ongoing OpenJFX development".  Clearly I was under
>>the misapprehension that it was about unicorns, angels and aliens.
>> 
>>However, the word "ongoing" probably could do with some
>>clarification.
>> 
>>Oh, and I don't actually *need* to find a forum to discuss
>>telephony equipment used 

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Thanks you most sincerely Dalibor for that very direct response.

Only... it wasn't really, was it?

You "believe I am entitled to a clear answer to my question".

Great! *So why have you still not answered it?*

Let me put it another way *so as there can be no possible room for any
further confusion (hopefully)*.

*COULD YOU PLEASE DETAIL EXACTLY WHERE JAVAFX IS USED IN EITHER PRODUCTS
USED INTERNALLY BY ORACLE OR IN COMMERCIAL PRODUCTS WHICH ORACLE MARKETS?*

Now, please give me the "clear answer" that I "am entitled to" (Your words,
not mine).

(Given that we now know that usage of JavaFX within JMX is about to be
abandoned, and there may be a tiny fraction of JMC that is still gasping
for air written using JavaFX, but knowing how *incredibly enthusiastically
Oracle is advancing JavaFX*, I *know* there must be hundreds more examples
and I am sure we would all love to hear about them).  That would give us
all a lot more faith in JavaFX. I am sure you want that don't you?

See - no mention of age of participants, telephony equipment or career
plans! Just JMX and a lot about OpenJFX!

Am I *still* in the wrong forum?

All my blessings,

Felix

P.S. What is this "bitterness" that you speak of?



On 13 June 2016 at 19:55, dalibor topic <dalibor.to...@oracle.com> wrote:

> Felix, I believe that you are entitled to a clear answer to your question:
>
> Yes, I have considered a career in politics.
>
> That being said, I would kindly suggest that you stop trying to divert[0]
> technical discussions in this community with off-topic posts, such as your
> contributions to this thread so far, where you attempted to discuss :
>
>  * the age of discussion participants,
>  * their telephony equipment and
>  * career plans,
>
> none of which have anything to do with JMX or OpenJFX.
>
> Instead, you should consider unsubscribing from this mailing list for a
> week or two, in order to get clarity in what capacity, if any, you'd like
> to positively contribute to ongoing OpenJFX development.
>
> As it stands, your current mode of participation on this mailing list is a
> net loss for this community, and apparently, for yourself as well, judging
> by what seems to be an increasing amount of bitterness in your posts.
>
> You can change that.
>
> All the best,
> Dalibor Topic
>
> [0] https://joeyh.name/blog/entry/thread_patterns/
>
>
> On 10.06.2016 15:29, Felix Bembrick wrote:
>
>> Dalibor, please forgive me for assuming that Oracle had access to an
>> English language parser. I could translate my original question into
>> Klingon and resubmit if that would help.
>>
>> And thanks so much for pointing out to me that this forum is devoted to
>> "ongoing OpenJFX development".  Clearly I was under the misapprehension
>> that it was about unicorns, angels and aliens.
>>
>> However, the word "ongoing" probably could do with some clarification.
>>
>> Oh, and I don't actually *need* to find a forum to discuss telephony
>> equipment used by other organisations because such information is
>> transparent and clearly indicates belief and commitment to their own
>> technologies.
>>
>> Just out of interest, have you ever considered a career in politics?
>>
>> And thanks for finally answering my question (even if it was
>> accidental)...
>>
>> On 10 Jun 2016, at 22:59, Dalibor Topic <dalibor.to...@oracle.com> wrote:
>>>
>>> Felix, unfortunately your original question was not parse-able.
>>>
>>> Before you go on prolonging this thread with more of that, please
>>> consider that this mailing list is for discussion of ongoing OpenJFX
>>> development.
>>>
>>> If instead you would prefer to discuss something else, please do try to
>>> find a more suitable venue for discussion of such interests. While I can't
>>> help you find an adequate forum to discuss telephony equipment used by
>>> employees of other organizations, I hope that you will be able to find a
>>> better place to do so in the future.
>>>
>>> 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.
>>>

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Kudos on the "imagination" part...

You are at least possibly right about Cisco.

And your quote "but only if they knew it wasn't going to disappear" is a nice 
summary of the intent of my reasonable question that never got "officially" 
answered.

But then again, it was somewhat rhetorical in nature and the politician-styled 
responses and misdirection that followed were both expected and provided 
clarity-by-accident (or CBA - my new TLA for the day)...

> On 11 Jun 2016, at 00:43, Mark Fortner <phidia...@gmail.com> wrote:
> 
> Back to the original topic, since JMX is used to monitor servers and 
> applications, and since most of us don't write monitoring software, the 
> audience for it is by definition small.
> 
> I would imagine that Oracle and perhaps a Cisco (or companies involved in 
> network monitoring) would be interested, but only if they knew it wasn't 
> going to disappear.
> 
> Mark
> 
>> On Jun 10, 2016 6:29 AM, "Felix Bembrick" <felix.bembr...@gmail.com> wrote:
>> Dalibor, please forgive me for assuming that Oracle had access to an English 
>> language parser. I could translate my original question into Klingon and 
>> resubmit if that would help.
>> 
>> And thanks so much for pointing out to me that this forum is devoted to 
>> "ongoing OpenJFX development".  Clearly I was under the misapprehension that 
>> it was about unicorns, angels and aliens.
>> 
>> However, the word "ongoing" probably could do with some clarification.
>> 
>> Oh, and I don't actually *need* to find a forum to discuss telephony 
>> equipment used by other organisations because such information is 
>> transparent and clearly indicates belief and commitment to their own 
>> technologies.
>> 
>> Just out of interest, have you ever considered a career in politics?
>> 
>> And thanks for finally answering my question (even if it was accidental)...
>> 
>> > On 10 Jun 2016, at 22:59, Dalibor Topic <dalibor.to...@oracle.com> wrote:
>> >
>> > Felix, unfortunately your original question was not parse-able.
>> >
>> > Before you go on prolonging this thread with more of that, please consider 
>> > that this mailing list is for discussion of ongoing OpenJFX development.
>> >
>> > If instead you would prefer to discuss something else, please do try to 
>> > find a more suitable venue for discussion of such interests. While I can't 
>> > help you find an adequate forum to discuss telephony equipment used by 
>> > employees of other organizations, I hope that you will be able to find a 
>> > better place to do so in the future.
>> >
>> > 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, Jan Schultheiss, Val Maher
>> >
>> > <http://www.oracle.com/commitment> Oracle is committed to developing
>> > practices and products that help protect the environment
>> >
>> >> On 10.06.2016, at 12:46, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> >>
>> >> I am taking that as a "yes" answer to my original question.
>> >>
>> >> On a completely unrelated topic, do Microsoft employees all have Macs on 
>> >> their desktops and carry iPhones and iPads around?
>> >>
>> >> No?
>> >>
>> >> Well I bet Apple employees do!
>> >>
>> >>> On 10 Jun 2016, at 20:01, dalibor topic <dalibor.to...@oracle.com> wrote:
>> >>>
>> >>> I suspect that particular plugin is extremely rarely used, judging by 
>> >>> https://github.com/search?utf8=%E2%9C%93=%22javafx-mx.jar%22=Code=searchresults
>> >>>  showing 0 results.
>> >>>
>> >>> cheers,
>> >>> dalibor topic
>> >>>
>> >>>> On 09.06.2016 00:31, 

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Dalibor, please forgive me for assuming that Oracle had access to an English 
language parser. I could translate my original question into Klingon and 
resubmit if that would help.

And thanks so much for pointing out to me that this forum is devoted to 
"ongoing OpenJFX development".  Clearly I was under the misapprehension that it 
was about unicorns, angels and aliens.

However, the word "ongoing" probably could do with some clarification.

Oh, and I don't actually *need* to find a forum to discuss telephony equipment 
used by other organisations because such information is transparent and clearly 
indicates belief and commitment to their own technologies.

Just out of interest, have you ever considered a career in politics?

And thanks for finally answering my question (even if it was accidental)...

> On 10 Jun 2016, at 22:59, Dalibor Topic <dalibor.to...@oracle.com> wrote:
> 
> Felix, unfortunately your original question was not parse-able. 
> 
> Before you go on prolonging this thread with more of that, please consider 
> that this mailing list is for discussion of ongoing OpenJFX development.
> 
> If instead you would prefer to discuss something else, please do try to find 
> a more suitable venue for discussion of such interests. While I can't help 
> you find an adequate forum to discuss telephony equipment used by employees 
> of other organizations, I hope that you will be able to find a better place 
> to do so in the future.
> 
> 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, Jan Schultheiss, Val Maher
> 
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
> 
>> On 10.06.2016, at 12:46, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> 
>> I am taking that as a "yes" answer to my original question.
>> 
>> On a completely unrelated topic, do Microsoft employees all have Macs on 
>> their desktops and carry iPhones and iPads around?
>> 
>> No?
>> 
>> Well I bet Apple employees do!
>> 
>>> On 10 Jun 2016, at 20:01, dalibor topic <dalibor.to...@oracle.com> wrote:
>>> 
>>> I suspect that particular plugin is extremely rarely used, judging by 
>>> https://github.com/search?utf8=%E2%9C%93=%22javafx-mx.jar%22=Code=searchresults
>>>  showing 0 results.
>>> 
>>> cheers,
>>> dalibor topic
>>> 
>>>> On 09.06.2016 00:31, Kevin Rushforth wrote:
>>>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>>>> separate jar file along with the JDK (not part of the JRE) in
>>>> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK
>>>> 8 being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>>>> 
>>>> Are there any developers that still use this? We haven't seen any bug
>>>> reports or had questions on it for quite a while. I note that this jar
>>>> file has been gone from JDK 9 ea since build 111 and we are trying to
>>>> determine how best to address this in JDK 9.
>>>> 
>>>> Our options are:
>>>> 
>>>> 1) Remove it entirely and drop this tooling support
>>>> 
>>>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>>>> require command line qualified exports to be added since it uses
>>>> internal packages
>>>> 
>>>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be
>>>> one of the default modules, so it would need to be added with -addmods.
>>>> 
>>>> Obviously #1 would be the least amount of work, and given that it isn't
>>>> being actively maintained, might be a viable solution. If we do need to
>>>> keep it, then #2 might be less effort than #3, while still preserving
>>>> the ability for developers to use it. This is only used for tooling, so
>>>> requiring qualified exports, as is done for Robot and
>>>> PerformanceTracker, is not a prob

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Did you even read the email you are replying to? Or the email I was myself 
replying to?

If I have spell it out so bluntly that everyone can understand then I will only 
get myself into further trouble with the "Big O".

I used a technique known locally as "sarcasm". It's sort of the default mode of 
communication in this country.

But I assumed most people could "join the dots" regardless of where they are 
located...

P.S. Again, on a completely unrelated note, are you planning to use Java EE 8? 
If so, how old are you?

> On 10 Jun 2016, at 22:01, Ranie Jade Ramiso <raniejaderam...@gmail.com> wrote:
> 
> Okay this thread is about what to do with javafx jmx plugin. How does that 
> even relate to whether oracle is using javafx internally?
> 
> 
>> On Fri, Jun 10, 2016, 7:52 PM Felix Bembrick <felix.bembr...@gmail.com> 
>> wrote:
>> Unfortunately, it has a lot to do with it.
>> 
>> Do you actually realise how much of the entire JMC is written using JavaFX? 
>> (Not to mention what percentage of Java developers even know about or use 
>> JMC).
>> 
>> Please check and then feel free to respond and enlighten us all with your 
>> findings.  100%? At least 90% surely? Hmm...
>> 
>> And, if there are actually any *other* "vestiges" of JavaFX usage within 
>> Oracle, I would be delighted to hear about them!
>> 
>> In fact, I am confident the entire JavaFX community would absolutely love to 
>> hear that it's obviously being used in  hundreds of internal applications 
>> (especially with Oracle being such a huge Java-focused company).  I mean it 
>> is the "standard" way of building GUI applications with Java right? So of 
>> course they would have no reason whatsoever to not base their entire 
>> internal software product suite on this advanced and clearly well supported 
>> technology.
>> 
>> And throw in the dozens of commercial JavaFX offerings from Oracle and...
>> 
>> > On 10 Jun 2016, at 21:01, Tom Schindl <tom.schi...@bestsolution.at> wrote:
>> >
>> > What has the removal of JMX for JavaFX todo with Oracle using JavaFX
>> > themselves?
>> >
>> > There are projects at Oracle who for sure do use JavaFX and one of them
>> > is installed in your JDK! It's Java-Mission-Control.
>> >
>> > Tom
>> >
>> >> On 10.06.16 12:46, Felix Bembrick wrote:
>> >> I am taking that as a "yes" answer to my original question.
>> >>
>> >> On a completely unrelated topic, do Microsoft employees all have Macs on 
>> >> their desktops and carry iPhones and iPads around?
>> >>
>> >> No?
>> >>
>> >> Well I bet Apple employees do!
>> >>
>> >>> On 10 Jun 2016, at 20:01, dalibor topic <dalibor.to...@oracle.com> wrote:
>> >>>
>> >>> I suspect that particular plugin is extremely rarely used, judging by 
>> >>> https://github.com/search?utf8=%E2%9C%93=%22javafx-mx.jar%22=Code=searchresults
>> >>>  showing 0 results.
>> >>>
>> >>> cheers,
>> >>> dalibor topic
>> >>>
>> >>>> On 09.06.2016 00:31, Kevin Rushforth wrote:
>> >>>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>> >>>> separate jar file along with the JDK (not part of the JRE) in
>> >>>> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK
>> >>>> 8 being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>> >>>>
>> >>>> Are there any developers that still use this? We haven't seen any bug
>> >>>> reports or had questions on it for quite a while. I note that this jar
>> >>>> file has been gone from JDK 9 ea since build 111 and we are trying to
>> >>>> determine how best to address this in JDK 9.
>> >>>>
>> >>>> Our options are:
>> >>>>
>> >>>> 1) Remove it entirely and drop this tooling support
>> >>>>
>> >>>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>> >>>> require command line qualified exports to be added since it uses
>> >>>> internal packages
>> >>>>
>> >>>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be
>> >>>> one of the default modules, so it would need to be added with -addmods.
>> >>>>
>> >>

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

Unfortunately, it has a lot to do with it.

Do you actually realise how much of the entire JMC is written using JavaFX? 
(Not to mention what percentage of Java developers even know about or use JMC).

Please check and then feel free to respond and enlighten us all with your 
findings.  100%? At least 90% surely? Hmm...

And, if there are actually any *other* "vestiges" of JavaFX usage within 
Oracle, I would be delighted to hear about them!

In fact, I am confident the entire JavaFX community would absolutely love to 
hear that it's obviously being used in  hundreds of internal applications 
(especially with Oracle being such a huge Java-focused company).  I mean it is 
the "standard" way of building GUI applications with Java right? So of course 
they would have no reason whatsoever to not base their entire internal software 
product suite on this advanced and clearly well supported technology.

And throw in the dozens of commercial JavaFX offerings from Oracle and...

> On 10 Jun 2016, at 21:01, Tom Schindl <tom.schi...@bestsolution.at> wrote:
> 
> What has the removal of JMX for JavaFX todo with Oracle using JavaFX
> themselves?
> 
> There are projects at Oracle who for sure do use JavaFX and one of them
> is installed in your JDK! It's Java-Mission-Control.
> 
> Tom
> 
>> On 10.06.16 12:46, Felix Bembrick wrote:
>> I am taking that as a "yes" answer to my original question.
>> 
>> On a completely unrelated topic, do Microsoft employees all have Macs on 
>> their desktops and carry iPhones and iPads around?
>> 
>> No?
>> 
>> Well I bet Apple employees do!
>> 
>>> On 10 Jun 2016, at 20:01, dalibor topic <dalibor.to...@oracle.com> wrote:
>>> 
>>> I suspect that particular plugin is extremely rarely used, judging by 
>>> https://github.com/search?utf8=%E2%9C%93=%22javafx-mx.jar%22=Code=searchresults
>>>  showing 0 results.
>>> 
>>> cheers,
>>> dalibor topic
>>> 
>>>> On 09.06.2016 00:31, Kevin Rushforth wrote:
>>>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>>>> separate jar file along with the JDK (not part of the JRE) in
>>>> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK
>>>> 8 being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>>>> 
>>>> Are there any developers that still use this? We haven't seen any bug
>>>> reports or had questions on it for quite a while. I note that this jar
>>>> file has been gone from JDK 9 ea since build 111 and we are trying to
>>>> determine how best to address this in JDK 9.
>>>> 
>>>> Our options are:
>>>> 
>>>> 1) Remove it entirely and drop this tooling support
>>>> 
>>>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>>>> require command line qualified exports to be added since it uses
>>>> internal packages
>>>> 
>>>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be
>>>> one of the default modules, so it would need to be added with -addmods.
>>>> 
>>>> Obviously #1 would be the least amount of work, and given that it isn't
>>>> being actively maintained, might be a viable solution. If we do need to
>>>> keep it, then #2 might be less effort than #3, while still preserving
>>>> the ability for developers to use it. This is only used for tooling, so
>>>> requiring qualified exports, as is done for Robot and
>>>> PerformanceTracker, is not a problem.
>>>> 
>>>> Separately, if we don't remove it for JDK 9, we probably will deprecate
>>>> it with the intention to remove it in a future release.
>>>> 
>>>> -- Kevin
>>> 
>>> -- 
>>> <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, Jan Schultheiss, Val Maher
>>> 
>>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>> practices and products that help protect the environment
> 
> 
> -- 
> 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: Anyone using JMX with JavaFX?

[Felix Bembrick]

I am taking that as a "yes" answer to my original question.

On a completely unrelated topic, do Microsoft employees all have Macs on their 
desktops and carry iPhones and iPads around?

No?

Well I bet Apple employees do!

> On 10 Jun 2016, at 20:01, dalibor topic  wrote:
> 
> I suspect that particular plugin is extremely rarely used, judging by 
> https://github.com/search?utf8=%E2%9C%93=%22javafx-mx.jar%22=Code=searchresults
>  showing 0 results.
> 
> cheers,
> dalibor topic
> 
>> On 09.06.2016 00:31, Kevin Rushforth wrote:
>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>> separate jar file along with the JDK (not part of the JRE) in
>> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK
>> 8 being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>> 
>> Are there any developers that still use this? We haven't seen any bug
>> reports or had questions on it for quite a while. I note that this jar
>> file has been gone from JDK 9 ea since build 111 and we are trying to
>> determine how best to address this in JDK 9.
>> 
>> Our options are:
>> 
>> 1) Remove it entirely and drop this tooling support
>> 
>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>> require command line qualified exports to be added since it uses
>> internal packages
>> 
>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be
>> one of the default modules, so it would need to be added with -addmods.
>> 
>> Obviously #1 would be the least amount of work, and given that it isn't
>> being actively maintained, might be a viable solution. If we do need to
>> keep it, then #2 might be less effort than #3, while still preserving
>> the ability for developers to use it. This is only used for tooling, so
>> requiring qualified exports, as is done for Robot and
>> PerformanceTracker, is not a problem.
>> 
>> Separately, if we don't remove it for JDK 9, we probably will deprecate
>> it with the intention to remove it in a future release.
>> 
>> -- Kevin
> 
> -- 
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +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, Jan Schultheiss, Val Maher
> 
>  Oracle is committed to developing
> practices and products that help protect the environment

Full speed animation - shouldn't the default value be true?

[Felix Bembrick]

I am just curious, why is the system property to enable "full speed
animations" in JavaFX applications NOT set to "true" by default?

Thanks,

Felix

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

I am sorry if this is a question you would prefer not to answer but I
believe the answer is significant.

I am sure the entire JavaFX community would love to know if Oracle "eats
their own dog food" so to speak.

Felix

On 9 June 2016 at 10:02, Felix Bembrick <felix.bembr...@gmail.com> wrote:

> So, if I'm not correct, does that mean that by choosing option 1, there
> will no remaining usage of JavaFX internally by Oracle themselves?
>
> Felix
>
> On 9 June 2016 at 08:31, Kevin Rushforth <kevin.rushfo...@oracle.com>
> wrote:
>
>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>> separate jar file along with the JDK (not part of the JRE) in
>> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK 8
>> being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>>
>> Are there any developers that still use this? We haven't seen any bug
>> reports or had questions on it for quite a while. I note that this jar file
>> has been gone from JDK 9 ea since build 111 and we are trying to determine
>> how best to address this in JDK 9.
>>
>> Our options are:
>>
>> 1) Remove it entirely and drop this tooling support
>>
>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>> require command line qualified exports to be added since it uses internal
>> packages
>>
>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be one
>> of the default modules, so it would need to be added with -addmods.
>>
>> Obviously #1 would be the least amount of work, and given that it isn't
>> being actively maintained, might be a viable solution. If we do need to
>> keep it, then #2 might be less effort than #3, while still preserving the
>> ability for developers to use it. This is only used for tooling, so
>> requiring qualified exports, as is done for Robot and PerformanceTracker,
>> is not a problem.
>>
>> Separately, if we don't remove it for JDK 9, we probably will deprecate
>> it with the intention to remove it in a future release.
>>
>> -- Kevin
>>
>>
>

Re: Anyone using JMX with JavaFX?

[Felix Bembrick]

So, if I'm not correct, does that mean that by choosing option 1, there
will no remaining usage of JavaFX internally by Oracle themselves?

Felix

On 9 June 2016 at 08:31, Kevin Rushforth  wrote:

> As some of you may be aware, JavaFX has shipped a JMX plugin as a separate
> jar file along with the JDK (not part of the JRE) in
> /lib/javafx-mx.jar. Development on this plugin stopped prior to JDK 8
> being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>
> Are there any developers that still use this? We haven't seen any bug
> reports or had questions on it for quite a while. I note that this jar file
> has been gone from JDK 9 ea since build 111 and we are trying to determine
> how best to address this in JDK 9.
>
> Our options are:
>
> 1) Remove it entirely and drop this tooling support
>
> 2) Continue to ship it as a legacy jar file, meaning that any use would
> require command line qualified exports to be added since it uses internal
> packages
>
> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be one
> of the default modules, so it would need to be added with -addmods.
>
> Obviously #1 would be the least amount of work, and given that it isn't
> being actively maintained, might be a viable solution. If we do need to
> keep it, then #2 might be less effort than #3, while still preserving the
> ability for developers to use it. This is only used for tooling, so
> requiring qualified exports, as is done for Robot and PerformanceTracker,
> is not a problem.
>
> Separately, if we don't remove it for JDK 9, we probably will deprecate it
> with the intention to remove it in a future release.
>
> -- Kevin
>
>

Re: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week.

[Felix Bembrick]

 Can you at least let me know why the JavaFX usage of WebKit does *not* support 
WebGL when native WebKit itself always has?

Is there some technical or architectural barrier?

> On 27 May 2016, at 22:51, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
> 
> No, I don't have anything further to add about WebGL, if that's what you are 
> asking.
> 
> As for moving to Blink, that would be a very large effort. We do not 
> currently plan to do this for JDK 10, but could reevaluate it in the future 
> if something changes.
> 
> -- Kevin
> 
> 
> Felix Bembrick wrote:
>> Any comments on this? Isn't it time to move to Blink?
>> 
>>  
>>> On 13 May 2016, at 04:32, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>> 
>>> Thanks Kevin.
>>> 
>>> I was more curious as to why WebGL support hasn't been there since day 1, 
>>> given that WebKit itself supports it.
>>> 
>>> Felix
>>> 
>>>
>>>> On 13 May 2016, at 01:52, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>> wrote:
>>>> 
>>>> It was an issue of resources versus priority and scope. JDK 9 is focused 
>>>> on Jigsaw modularity and a few other minor features. It is more of a 
>>>> "smoothing out" release than a big feature release (except for Jigsaw). We 
>>>> expect JDK 10 to be a somewhat more feature-oriented release.
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> Felix Bembrick wrote:
>>>>  
>>>>> Do you mind if I ask what the rationale behind such a decision is?
>>>>> 
>>>>> From an admittedly perhaps totally ignorant outside observer, it would 
>>>>> seem to me that any cost/benefit analysis would basically put this 
>>>>> feature in the "no brainer" category and should have been implemented at 
>>>>> the very least since JFX 8.
>>>>> 
>>>>> 
>>>>>
>>>>>> On 12 May 2016, at 01:11, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>>> wrote:
>>>>>> 
>>>>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 
>>>>>> 10.
>>>>>> 
>>>>>> -- Kevin
>>>>>> 
>>>>>> 
>>>>>> Felix Bembrick wrote:
>>>>>> 
>>>>>>  
>>>>>>> Will this new WebKit finally support WebGL?
>>>>>>> 
>>>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an 
>>>>>>> entire new set of 3D features and access to a plethora of JavaScript 3D 
>>>>>>> libraries for "free".
>>>>>>> 
>>>>>>> And, Google Maps will finally work too.
>>>>>>> 
>>>>>>> 
>>>>>>>
>>>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> All,
>>>>>>>> 
>>>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early 
>>>>>>>> next week [1]. If there are no build problems, they will be integrated 
>>>>>>>> to 9 master the following week for jdk-9+119. We then plan to backport 
>>>>>>>> the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later.
>>>>>>>> 
>>>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or 
>>>>>>>> later (we will use 3.4.1 to build).
>>>>>>>> 
>>>>>>>> Let me know if you have any questions.
>>>>>>>> 
>>>>>>>> -- Kevin
>>>>>>>> 
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698
>>>>>>>> 
>>>>>>>> [2] http://cmake.org/
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  

Re: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week.

[Felix Bembrick]

Any comments on this? Isn't it time to move to Blink?

> On 13 May 2016, at 04:32, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> Thanks Kevin.
> 
> I was more curious as to why WebGL support hasn't been there since day 1, 
> given that WebKit itself supports it.
> 
> Felix
> 
>> On 13 May 2016, at 01:52, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
>> 
>> It was an issue of resources versus priority and scope. JDK 9 is focused on 
>> Jigsaw modularity and a few other minor features. It is more of a "smoothing 
>> out" release than a big feature release (except for Jigsaw). We expect JDK 
>> 10 to be a somewhat more feature-oriented release.
>> 
>> -- Kevin
>> 
>> 
>> Felix Bembrick wrote:
>>> Do you mind if I ask what the rationale behind such a decision is?
>>> 
>>> From an admittedly perhaps totally ignorant outside observer, it would seem 
>>> to me that any cost/benefit analysis would basically put this feature in 
>>> the "no brainer" category and should have been implemented at the very 
>>> least since JFX 8.
>>> 
>>> 
>>>> On 12 May 2016, at 01:11, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>> wrote:
>>>> 
>>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 
>>>> 10.
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> Felix Bembrick wrote:
>>>> 
>>>>> Will this new WebKit finally support WebGL?
>>>>> 
>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an 
>>>>> entire new set of 3D features and access to a plethora of JavaScript 3D 
>>>>> libraries for "free".
>>>>> 
>>>>> And, Google Maps will finally work too.
>>>>> 
>>>>> 
>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>>> wrote:
>>>>>> 
>>>>>> All,
>>>>>> 
>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next 
>>>>>> week [1]. If there are no build problems, they will be integrated to 9 
>>>>>> master the following week for jdk-9+119. We then plan to backport the 
>>>>>> newer WebKit (to keep them in sync) to 8u-dev a couple weeks later.
>>>>>> 
>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later 
>>>>>> (we will use 3.4.1 to build).
>>>>>> 
>>>>>> Let me know if you have any questions.
>>>>>> 
>>>>>> -- Kevin
>>>>>> 
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698
>>>>>> 
>>>>>> [2] http://cmake.org/
>>>>>> 
>>>>>> 

Re: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week.

[Felix Bembrick]

Thanks Kevin.

I was more curious as to why WebGL support hasn't been there since day 1, given 
that WebKit itself supports it.

Felix

> On 13 May 2016, at 01:52, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
> 
> It was an issue of resources versus priority and scope. JDK 9 is focused on 
> Jigsaw modularity and a few other minor features. It is more of a "smoothing 
> out" release than a big feature release (except for Jigsaw). We expect JDK 10 
> to be a somewhat more feature-oriented release.
> 
> -- Kevin
> 
> 
> Felix Bembrick wrote:
>> Do you mind if I ask what the rationale behind such a decision is?
>> 
>> From an admittedly perhaps totally ignorant outside observer, it would seem 
>> to me that any cost/benefit analysis would basically put this feature in the 
>> "no brainer" category and should have been implemented at the very least 
>> since JFX 8.
>> 
>>  
>>> On 12 May 2016, at 01:11, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>> wrote:
>>> 
>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> Felix Bembrick wrote:
>>>
>>>> Will this new WebKit finally support WebGL?
>>>> 
>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an 
>>>> entire new set of 3D features and access to a plethora of JavaScript 3D 
>>>> libraries for "free".
>>>> 
>>>> And, Google Maps will finally work too.
>>>> 
>>>>   
>>>>> On 11 May 2016, at 08:20, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> All,
>>>>> 
>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next 
>>>>> week [1]. If there are no build problems, they will be integrated to 9 
>>>>> master the following week for jdk-9+119. We then plan to backport the 
>>>>> newer WebKit (to keep them in sync) to 8u-dev a couple weeks later.
>>>>> 
>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later 
>>>>> (we will use 3.4.1 to build).
>>>>> 
>>>>> Let me know if you have any questions.
>>>>> 
>>>>> -- Kevin
>>>>> 
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698
>>>>> 
>>>>> [2] http://cmake.org/
>>>>> 
>>>>>   

Re: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week.

[Felix Bembrick]

Do you mind if I ask what the rationale behind such a decision is?

From an admittedly perhaps totally ignorant outside observer, it would seem to 
me that any cost/benefit analysis would basically put this feature in the "no 
brainer" category and should have been implemented at the very least since JFX 
8.

> On 12 May 2016, at 01:11, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
> 
> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10.
> 
> -- Kevin
> 
> 
> Felix Bembrick wrote:
>> Will this new WebKit finally support WebGL?
>> 
>> Just by supporting WebGL in the JavaFX WebView will instantly enable an 
>> entire new set of 3D features and access to a plethora of JavaScript 3D 
>> libraries for "free".
>> 
>> And, Google Maps will finally work too.
>> 
>>  
>>> On 11 May 2016, at 08:20, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>> wrote:
>>> 
>>> All,
>>> 
>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next 
>>> week [1]. If there are no build problems, they will be integrated to 9 
>>> master the following week for jdk-9+119. We then plan to backport the newer 
>>> WebKit (to keep them in sync) to 8u-dev a couple weeks later.
>>> 
>>> The only new tool needed to build this is CMake [2] version 3.4 or later 
>>> (we will use 3.4.1 to build).
>>> 
>>> Let me know if you have any questions.
>>> 
>>> -- Kevin
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698
>>> 
>>> [2] http://cmake.org/
>>> 
>>>

Re: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week.

[Felix Bembrick]

Will this new WebKit finally support WebGL?

Just by supporting WebGL in the JavaFX WebView will instantly enable an entire 
new set of 3D features and access to a plethora of JavaScript 3D libraries for 
"free".

And, Google Maps will finally work too.

> On 11 May 2016, at 08:20, Kevin Rushforth  wrote:
> 
> All,
> 
> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week 
> [1]. If there are no build problems, they will be integrated to 9 master the 
> following week for jdk-9+119. We then plan to backport the newer WebKit (to 
> keep them in sync) to 8u-dev a couple weeks later.
> 
> The only new tool needed to build this is CMake [2] version 3.4 or later (we 
> will use 3.4.1 to build).
> 
> Let me know if you have any questions.
> 
> -- Kevin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8156698
> 
> [2] http://cmake.org/
> 

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

Well I did ask Johan what AOT they are going to use instead of RoboVM but there 
has not be a response yet.

Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles is 
simply not viable which in turn implies that JavaFX itself is not even worth 
looking at... RIP.

But I take Johan on his word that the demise of RoboVM will not negatively 
affect Gluon or its products and he has done absolutely amazing things 
throughout his career. So I am assuming he as a plan B.

I really wish Gluon somehow took complete ownership of the entire OpenJFX 
project as JavaFX could not be in safer hands.

> On 19 Apr 2016, at 17:43, Tobi <t...@ultramixer.com> wrote:
> 
> Hi,
> 
> in my opinion the abandonment of RoboVM is a very big step back for Java on 
> Mobile because there is NO real alternative to RoboVM. So it has definitely a 
> big impact on Gluon and JavaFX on Mobile. Gluon uses RoboVM 1.8 - and old 
> version of RoboVM which will be not developed anymore. So no serious company 
> will decide to use a technology which is winding down! 
> 
> So ok, what could Gluon do now? Using OpenJDK9 for iOS and Android? Currently 
> definitely not! OpenJDK9 for Mobile is in an experimental state and uses the 
> Zero interpreter! So the performance will be not acceptable until the OpenJDK 
> 9 provides the same level of AOT like RoboVM - or even better! 
> 
> What can we do now to reach the goal to develop modern mobile applications 
> with Java - instead of with Xamarian…?
> 
> We need as soon as possible one or more companies to continue the development 
> of one of the RoboVM 1.8 forks (like BugVM) or merge the know how of RoboVM 
> with the current OpenJDK9 efforts… We need commitments of big companies to 
> Java like Oracle, Intel, IBM, SAP! We need the RoboVM team which breaks out 
> of Microsofts Xamarian world! In my dreams Niklas, Henric and their team take 
> the money of Xamarian and Microsoft and revive their baby „RoboVM“ in the 
> context of a fork based on open sourced RoboVM 1.8… Maybe with in a join 
> venture with Intel (concerning Intel’s Multi-OS engine)
> 
> What do you think about it guys? What are your plans Niklas…?
> 
> Best regards,
> Tobi
> 
> //
> follow me on twitter: https://twitter.com/tobibley 
> <https://twitter.com/tobibley>
> 
> 
> 
> 
>> Am 18.04.2016 um 19:15 schrieb Johan Vos <johan@gluonhq.com>:
>> 
>> Indeed, this doesn't have any impact on JavaFX.
>> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last
>> open-source version.
>> 
>> RoboVM delivered a whole set of products, including an AOT, but also a
>> system that provides some JNI functionality, a set of bindings that create
>> Java classes that have a 1-1 mapping to native iOS classes, and a whole
>> "Studio" allowing developers to create applications.
>> 
>> Only the AOT is relevant to us. We don't use the bindings, as we happen to
>> have a great set of UI classes: the JavaFX platform. We don't need the
>> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse.
>> 
>> The idea of JavaFX is to deliver a cross-platform UI for all devices.
>> RoboVM took a different approach, as they mainly promoted creating an iOS
>> specific UI (using the Java bindings to the native iOS UI components) and
>> an Android specific UI.
>> 
>> We had different views on a cross-platform UI (JavaFX) versus a
>> platform-specific UI, but here is no doubt the RoboVM team consist of great
>> developers and it is a real pity and shame they won't be able to continue
>> working on their product.
>> 
>> But for JavaFX and Gluon, it doesn't make a difference.
>> 
>> - Johan
>> 
>> 
>>> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah <st...@weblite.ca> wrote:
>>> 
>>> According to Gluon, they're not impacted by this.
>>> https://twitter.com/GluonHQ/status/721784161728471041
>>> 
>>> 
>>> 
>>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <felix.bembr...@gmail.com>
>>> wrote:
>>> 
>>>> I just read this article which states that RoboVM is effectively
>>>> "shutting down".
>>>> 
>>>> https://www.voxxed.com/blog/2016/04/robovm/
>>>> 
>>>> Given that they seem to be a critical part of the puzzle that is making
>>>> JavaFX viable on mobile platforms, what does this actually mean for that
>>>> goal?
>>>> 
>>>> Is there an alternative technology or product that can fill this void? Or
>>>> is the final nail in the coffin for JavaFX to ever be a truly viable cross
>>>> platform technology?
>>>> 
>>>> Thanks,
>>>> 
>>>> Felix
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Steve Hannah
>>> Web Lite Solutions Corp.
> 

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

Good luck to you Erik. I totally agree with you and hope you succeed. If 
there's any way I can help, I will do just that.

Felix

> On 19 Apr 2016, at 04:39, Erik De Rijcke <derijcke.e...@gmail.com> wrote:
> 
> I'm currently looking if I can get some robovm fork kickstarted. (
> https://github.com/FlexoVM/flexovm/issues/4 ).
> 
> It's really a shame that for this one time Java has a real nice aot
> llvm compiler, MS kills it. Being able to compile Java (or any
> bytecode language) to a native, fast and small executable (especially
> for arm/embedded use which does not require an Oracle license) would
> be *really* cool. Let's see if we can continue to make this happen in
> one way or another.
> 
> On Mon, Apr 18, 2016 at 7:20 PM, Felix Bembrick
> <felix.bembr...@gmail.com> wrote:
>> So what AOT will you be using now? The last RoboVM AOT or something else?
>> 
>>> On 19 Apr 2016, at 03:15, Johan Vos <johan@gluonhq.com> wrote:
>>> 
>>> Indeed, this doesn't have any impact on JavaFX.
>>> The Gluon tools are currently using the RoboVM AOT 1.8, which was the last 
>>> open-source version.
>>> 
>>> RoboVM delivered a whole set of products, including an AOT, but also a 
>>> system that provides some JNI functionality, a set of bindings that create 
>>> Java classes that have a 1-1 mapping to native iOS classes, and a whole 
>>> "Studio" allowing developers to create applications.
>>> 
>>> Only the AOT is relevant to us. We don't use the bindings, as we happen to 
>>> have a great set of UI classes: the JavaFX platform. We don't need the 
>>> studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse.
>>> 
>>> The idea of JavaFX is to deliver a cross-platform UI for all devices. 
>>> RoboVM took a different approach, as they mainly promoted creating an iOS 
>>> specific UI (using the Java bindings to the native iOS UI components) and 
>>> an Android specific UI.
>>> 
>>> We had different views on a cross-platform UI (JavaFX) versus a 
>>> platform-specific UI, but here is no doubt the RoboVM team consist of great 
>>> developers and it is a real pity and shame they won't be able to continue 
>>> working on their product.
>>> 
>>> But for JavaFX and Gluon, it doesn't make a difference.
>>> 
>>> - Johan
>>> 
>>> 
>>>> On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah <st...@weblite.ca> wrote:
>>>> According to Gluon, they're not impacted by this.
>>>> https://twitter.com/GluonHQ/status/721784161728471041
>>>> 
>>>> 
>>>> 
>>>>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick 
>>>>> <felix.bembr...@gmail.com> wrote:
>>>>> I just read this article which states that RoboVM is effectively 
>>>>> "shutting down".
>>>>> 
>>>>> https://www.voxxed.com/blog/2016/04/robovm/
>>>>> 
>>>>> Given that they seem to be a critical part of the puzzle that is making 
>>>>> JavaFX viable on mobile platforms, what does this actually mean for that 
>>>>> goal?
>>>>> 
>>>>> Is there an alternative technology or product that can fill this void? Or 
>>>>> is the final nail in the coffin for JavaFX to ever be a truly viable 
>>>>> cross platform technology?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Felix
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Steve Hannah
>>>> Web Lite Solutions Corp.
>>> 

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

I wonder what the performance of alternatives to RoboVM is like...

> On 19 Apr 2016, at 03:09, Steve Hannah <st...@weblite.ca> wrote:
> 
> https://twitter.com/GluonHQ/status/721784242565357568
> 
> The Gluon blog post from a few months ago (when @robovm was acquired by
>> @xamarin) is still almost entirely relevant
>> http://gluonhq.com/gluon-supports-multiple-jvms/
> 
> 
> On Mon, Apr 18, 2016 at 10:07 AM, Felix Bembrick <felix.bembr...@gmail.com>
> wrote:
> 
>> So what do they use instead?
>> 
>>> On 19 Apr 2016, at 02:52, Steve Hannah <st...@weblite.ca> wrote:
>>> 
>>> According to Gluon, they're not impacted by this.
>>> https://twitter.com/GluonHQ/status/721784161728471041
>>> 
>>> 
>>> 
>>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <
>> felix.bembr...@gmail.com>
>>> wrote:
>>> 
>>>> I just read this article which states that RoboVM is effectively
>> "shutting
>>>> down".
>>>> 
>>>> https://www.voxxed.com/blog/2016/04/robovm/
>>>> 
>>>> Given that they seem to be a critical part of the puzzle that is making
>>>> JavaFX viable on mobile platforms, what does this actually mean for that
>>>> goal?
>>>> 
>>>> Is there an alternative technology or product that can fill this void?
>> Or
>>>> is the final nail in the coffin for JavaFX to ever be a truly viable
>> cross
>>>> platform technology?
>>>> 
>>>> Thanks,
> https://twitter.com/GluonHQ/status/721784242565357568
> 
> The Gluon blog post from a few months ago (when @robovm was acquired by
>> @xamarin) is still almost entirely relevant
>> http://gluonhq.com/gluon-supports-multiple-jvms/
> 
> 
> On Mon, Apr 18, 2016 at 10:07 AM, Felix Bembrick <felix.bembr...@gmail.com>
> wrote:
> 
>> So what do they use instead?
>> 
>>> On 19 Apr 2016, at 02:52, Steve Hannah <st...@weblite.ca> wrote:
>>> 
>>> According to Gluon, they're not impacted by this.
>>> https://twitter.com/GluonHQ/status/721784161728471041
>>> 
>>> 
>>> 
>>> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <
>> felix.bembr...@gmail.com>
>>> wrote:
>>> 
>>>> I just read this article which states that RoboVM is effectively
>> "shutting
>>>> down".
>>>> 
>>>> https://www.voxxed.com/blog/2016/04/robovm/
>>>> 
>>>> Given that they seem to be a critical part of the puzzle that is making
>>>> JavaFX viable on mobile platforms, what does this actually mean for that
>>>> goal?
>>>> 
>>>> Is there an alternative technology or product that can fill this void?
>> Or
>>>> is the final nail in the coffin for JavaFX to ever be a truly viable
>> cross
>>>> platform technology?
>>>> 
>>>> Thanks,
>>>> 
>>>> Felix
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Steve Hannah
>>> Web Lite Solutions Corp.
>>> 
>>> --94eb2c0561622831410530c52f17
>>> Content-Type: text/html; charset=UTF-8
>>> Content-Transfer-Encoding: quoted-printable
>>> 
>>> According to Gluon, theyre not impacted by
>> this.=
>>> https://twitter.com/GluonHQ/status/721784161728471041;>
>> https://t=
>>> witter.com/GluonHQ/status/721784161728471041
>> 

Re: What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

So what do they use instead?

> On 19 Apr 2016, at 02:52, Steve Hannah <st...@weblite.ca> wrote:
> 
> According to Gluon, they're not impacted by this.
> https://twitter.com/GluonHQ/status/721784161728471041
> 
> 
> 
> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <felix.bembr...@gmail.com>
> wrote:
> 
>> I just read this article which states that RoboVM is effectively "shutting
>> down".
>> 
>> https://www.voxxed.com/blog/2016/04/robovm/
>> 
>> Given that they seem to be a critical part of the puzzle that is making
>> JavaFX viable on mobile platforms, what does this actually mean for that
>> goal?
>> 
>> Is there an alternative technology or product that can fill this void? Or
>> is the final nail in the coffin for JavaFX to ever be a truly viable cross
>> platform technology?
>> 
>> Thanks,
>> 
>> Felix
> 
> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.
> 
> --94eb2c0561622831410530c52f17
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> According to Gluon, theyre not impacted by this.=
> https://twitter.com/GluonHQ/status/721784161728471041;>https://t=
> witter.com/GluonHQ/status/721784161728471041

What does this mean for the future of JavaFX on iOS?

[Felix Bembrick]

I just read this article which states that RoboVM is effectively "shutting 
down".

https://www.voxxed.com/blog/2016/04/robovm/

Given that they seem to be a critical part of the puzzle that is making JavaFX 
viable on mobile platforms, what does this actually mean for that goal?

Is there an alternative technology or product that can fill this void? Or is 
the final nail in the coffin for JavaFX to ever be a truly viable cross 
platform technology?

Thanks,

Felix

Re: Learning Prism

[Felix Bembrick]

+1

I too would love to dive as deep as possible and improve anything that
needs improving so some guidance would help greatly!

Felix

On 8 March 2016 at 14:45, Jeffrey Guenther 
wrote:

> Hi Devs,
>
> I’m interested in learning more about JavaFX’s low level graphics
> implementation. I’ve spent a couple afternoons source diving in the
> modules/graphics folder to get the lay of the land and now I think I need
> some help. Can anyone point me to documentation describing the system’s
> high level design? Let’s say one or two levels deeper than
> http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm? <
> http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm?>
>
> Ultimately, I’d like to gain a better understanding on how JavaFX lays out
> and renders text for the purposes of understanding how I might be able to
> contribute to a more advanced text API with support for things like kerning.
>
> Secondly, can anyone explain to me how shaders are compiled and passed
> down to the graphics layer? I’d like to gain a better understanding of how
> a JavaFX programmer could leverage/add to Prism such that we can write
> custom shaders/GPU kernels for Effects nodes.
>
> I realize the graphics system in JavaFX is not for the faint of heart.
> There’s much going on beneath the surface. I’m willing to dive deep and do
> the learning to understand the design. Can anyone point me to docs where I
> can get started? Or maybe which class to start with and work out from when
> I’m source diving?
>
> Jeff

Feature matrix

[Felix Bembrick]

I think developers would find it useful if there was a maintained spreadsheet 
that was kept as current as possible that details each major JavaFX feature and 
the status of its implementation on each platform.

The values could be something like "FULL" (the feature is fully implemented and 
working), "PARTIAL" (the feature is available but is not complete or suitable 
for production apps yet), "NONE" (the feature has not been implemented at all 
yet but will be eventually) and "NEVER" (for whatever reason, the feature will 
never be implemented on this platform).

This would be so helpful for developers targeting multiple platforms to know in 
advance which features are going to work on each platform as opposed to banging 
their head against a wall trying to make a non-functional feature work on a 
particular platform.

Ideally this would be hosted and maintained by Oracle though I suspect Gluon 
would have more information, especially for mobile platforms, and so it would 
be a nice addition to the Gluon website.

Does anyone else think they would find this useful? Could someone from Oracle 
and Gluon please respond?

Felix

Oracle's mobile JDK ports & JavaFX

[Felix Bembrick]

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

[Felix Bembrick]

Well, it is the official Swing replacement but look at Java 9 and you won't see 
many if any enhancements to JavaFX.  The point is Oracle has no interest in 
desktop software other than maintaining any existing support contracts.

I don't even think Oracle wants JavaFX so it would be better for everyone to 
take ownership of it and build a company purely around JavaFX that's actually 
profitable and keeps enhancing the product at a much faster pace.

> On 1 Dec 2015, at 19:12, i...@cuhka.com wrote:
> 
> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle 
> itself maintains the code doesn't really matter I think, but they have to put 
> support and development in it.
> 
> To me another downside if Oracle would suspend further development is that 
> any statements made by Oracle seem to carry not so much value. If I'm correct 
> JavaFX was presented by Oracle as the Swing replacement. If after a short 
> time they revert from that position, what would that mean for any other 
> statement?
> 
> 
> Citeren Felix Bembrick <felix.bembr...@gmail.com>:
> 
>> If JavaFX stays under Oracle control, it will be the same it is today in 5 
>> years. I really doubt they will put another dollar into its expansion and 
>> new features.
>> 
>> How can that be good?
>> 
>> Plus the company that does take over could provide commercial support as 
>> well as training (which Oracle doesn't).
> 
> 

Re: Future of JavaFX

[Felix Bembrick]

Is it really true that *all* of JavaFX is open source?

Even if it is, if I wanted to say take some aspects of the product in a radical 
new direction, wouldn't someone from Oracle have to approve the changes?

If yes, then only Oracle can bring the big enhancements that are necessary 
which we know will never happen.

As I said, the biggest impediment to the growth in features, performance and 
adoption of JavaFX is Oracle themselves.

> On 1 Dec 2015, at 20:45, Peter Pilgrim <peter.pilg...@gmail.com> wrote:
> 
> Hi All
> 
> I find it remarkable to see that this debate about
> innovation-versus-maintenance is similar to the one going on in the
> Java EE space. See
> https://java.net/projects/javaee-spec/lists/users/archive/2015-01/message/48
> - Many Java EE experts, including myself, are now looking at the
> application servers and the ability to modularise the EE
> specification, so that we can just launch an application with `java
> -jar acme.jar'. Of course, we are already wrong about that command
> line option, because the JDK 9 will be a game changer.
> 
> Anyway, Shai, has some valid interesting assertions in his blog entry.
> I don't think it is all FUD in the way that Microsoft used to secretly
> push in their strategic vision to conquer the desktop world. I do
> believe that his evidence shows how weak OTHER developers view Java
> client side technologies. JavaFX has not set the world on fire and has
> been the vision that I saw at the first presentation in JavaOne 2007.
> 
> But that was yesterday, 8 years ago in fact. I lot of mistakes were
> made, and the vision could have better. We all had to follow the
> education and the learning path. Hindsight is a beautiful thing, a lot
> of us though scripting languages were exciting back then. We should
> have started with an all Java API solution in the first place, but
> there you go...
> 
> Donald  said the JavaFX is 100% open source, so what is the real
> issue. We have the code, go and build.
> 
> Alexander, I downloaded your JavaOne presentation, I went through it
> last night. It is good stuff with all of those 11 business enterprise
> applications. Why are these applications not good enough to show
> adoption?
> 
> Last year, 2014, I watch a JavaFX talk at JavaOne on a financial
> trading system written in JavaFX (CelerFX or something). What gives
> here?
> 
> I am definitely a Java EE guy these days ever since I wrote two books,
> but you fellows need to step up, I think, promote FX more strongly
> yourselves. I know that Nandini (who is now at Twitter) pushed a FX
> show case a couple times in the past, first for JavaFX 1.0 and then
> 1.2. Jim did with blog and is still going at Pivotal. Guys you need to
> do more videos, screen captures and more talks. If the popular Java
> conferences don't take you on, then f*** e* and host your own video
> shows like Adam Bien. Build some excitement about what your have done
> with FX in your applications. Grow some con** and come down with
> the attitude.
> 
> The good news is that JDK 9 will bring a better deployment story for
> Java on the whole. You can have launchers and modules that only your
> application require. Perhaps, were the value is.
> 
> 
>> On 1 December 2015 at 08:21, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> Well, it is the official Swing replacement but look at Java 9 and you won't 
>> see many if any enhancements to JavaFX.  The point is Oracle has no interest 
>> in desktop software other than maintaining any existing support contracts.
>> 
>> I don't even think Oracle wants JavaFX so it would be better for everyone to 
>> take ownership of it and build a company purely around JavaFX that's 
>> actually profitable and keeps enhancing the product at a much faster pace.
>> 
>>> On 1 Dec 2015, at 19:12, i...@cuhka.com wrote:
>>> 
>>> If it is not a part of OpenJDK/Oracle JDK it will not work. Whether Oracle 
>>> itself maintains the code doesn't really matter I think, but they have to 
>>> put support and development in it.
>>> 
>>> To me another downside if Oracle would suspend further development is that 
>>> any statements made by Oracle seem to carry not so much value. If I'm 
>>> correct JavaFX was presented by Oracle as the Swing replacement. If after a 
>>> short time they revert from that position, what would that mean for any 
>>> other statement?
>>> 
>>> 
>>> Citeren Felix Bembrick <felix.bembr...@gmail.com>:
>>> 
>>>> If JavaFX stays under Oracle control, it will be the same it is today in 5 
>>>> years. I really doubt they will put another dollar into its expa

Re: Future of JavaFX

[Felix Bembrick]

The problem is that JavaFX is not used in any Oracle products (whereas Swing 
is), it makes them no money and it fact they are constantly bleeding while 
maintaining a team to develop a product that brings in no money and doesn't fit 
into their whole "cloud is everything" strategy.

I would say that from Oracles point of view, JavaFX will not be developed any 
further.

However, Gluon and RoboVM are doing their best to keep it alive but they are a 
very small under resourced team.

In my opinion, JavaFX should be jettisoned from the JDK and managed by a 
company like Gluon on all platforms and be monetised just like the very 
successful Qt Company which just sells and supports Qt. 

With JavaFX, Oracle are an impediment to its success. We need a "JavaFX 
Company" that will develop it, sell it and support it. It should be separate 
from the JDK so it can have its own independent and more frequent release cycle.

That's how to save JavaFX.

But I am probably dreaming...

> On 1 Dec 2015, at 09:54, Casall, Alexander  wrote:
> 
> 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: Future of JavaFX

[Felix Bembrick]

If JavaFX stays under Oracle control, it will be the same it is today in 5 
years. I really doubt they will put another dollar into its expansion and new 
features. 

How can that be good?

Plus the company that does take over could provide commercial support as well 
as training (which Oracle doesn't).

> On 1 Dec 2015, at 17:35, Casall, Alexander <alexander.cas...@saxsys.de> wrote:
> 
> I don't agree. To move it away from Oracle would be the official death of fx.
> And you could hire oracle engineering services, so there is commercial 
> support, if you have the money to pay for.
> 
> I think one option would be, that oracle engages commiters to contribute. In 
> addition the fx team should have the capacity to manage the open source 
> process, like doing a lot of reviews to assure the quality.
> 
> RoboVM is sold to xamarin, so they are not in he game anymore.
> 
> I think the solution could be:
> - more developers (even in India :-) )
> - make OpenJFX to a real open source project
> 
> - Alex 
> 
> From: Felix Bembrick
> Sent: 01.12.15, 03:00
> To: Casall, Alexander
> Cc: Donald Smith, openjfx mailing list
> Subject: Re: Future of JavaFX
> 
> The problem is that JavaFX is not used in any Oracle products (whereas Swing 
> is), it makes them no money and it fact they are constantly bleeding while 
> maintaining a team to develop a product that brings in no money and doesn't 
> fit into their whole "cloud is everything" strategy.
> 
> I would say that from Oracles point of view, JavaFX will not be developed any 
> further.
> 
> However, Gluon and RoboVM are doing their best to keep it alive but they are 
> a very small under resourced team.
> 
> In my opinion, JavaFX should be jettisoned from the JDK and managed by a 
> company like Gluon on all platforms and be monetised just like the very 
> successful Qt Company which just sells and supports Qt. 
> 
> With JavaFX, Oracle are an impediment to its success. We need a "JavaFX 
> Company" that will develop it, sell it and support it. It should be separate 
> from the JDK so it can have its own independent and more frequent release 
> cycle.
> 
> That's how to save JavaFX.
> 
> But I am probably dreaming...
> 
> > alexander.cas...@saxsys.de> wrote:
> > 
> > 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: pisces, produceFillAlphas

[Felix Bembrick]

Hi Johan,

Have you been able to find enough time to be able to answer this question? In 
my present situation, clarity on these issues is extremely important to me and 
I would guess to many others as well.

Thanks,

Felix 

> On 18 Oct 2015, at 19:01, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> Hi Johan,
> 
> If you have been getting acceptable but not stunning performance on Android 
> and all this time hardware acceleration was not being utilised then it sounds 
> like there is some serious room for some dramatic performance increases.
> 
> Not being that familiar with the finer points of how JavaFX is implemented on 
> Android, just how much work is involved in accessing that hardware 
> acceleration?  Any timeline?
> 
> I expect that implementing this significant change could be a make-or-break 
> factor in determining whether JavaFX is truly viable and successful on 
> Android.
> 
> Good luck Johan!
> 
> Cheers,
> 
> Felix 
> 
>> On 17 Oct 2015, at 19:49, Johan Vos <johan@gluonhq.com> wrote:
>> 
>> As a follow-up on the second part: after about 2 years working on JavaFX on
>> Android, I discovered we are not even using Hardware Acceleration. We
>> create a SurfaceView and render on that, but it turns out SurfaceView is
>> never Hardware Accelerated. The positive thing is that this means there is
>> even more room for optimization :)
>> 
>> - Johan
>> 
>>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos <johan@gluonhq.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for the suggestions. There are 2 different things:
>>> 
>>> 1. It seems indeed there is not much being cached, so there are definitely
>>> improvements possible. It also require e.g. VirtualFlow to use the
>>> Node.setCache(true) in order to cache. The combination of this with the
>>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty
>>> is memory, but so far, we didn't run into issues with too high GC activity.
>>> 
>>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
>>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
>>> I'll have to look into some EGL options.
>>> 
>>> - Johan
>>> 
>>> 
>>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham <james.gra...@oracle.com>
>>> wrote:
>>> 
>>>> Chien pointed out a system property that is currently disabling the
>>>> scrolling optimization.  For its implementation look at CacheFilter.java,
>>>> in particular the invalidateByTranslation() method and all that it kicks
>>>> off.
>>>> 
>>>> Another thing to look at is that we added alpha batching to the code
>>>> which should be batching all of the output of the produceAlphas calls into
>>>> a texture and then drawing all of the quads together - provided that they
>>>> are all being filled with simple colors (they can have alpha, but they
>>>> can't be gradients, etc.).  This should be managed by the
>>>> BaseContext.updateMaskTexture() method which controls the single batch
>>>> texture.
>>>> 
>>>> Again, are there similar number of invocations of the glDrawElements on
>>>> the 2 platforms?
>>>> 
>>>>   ...jim
>>>> 
>>>>> On 10/15/15 12:30 PM, Johan Vos wrote:
>>>>> 
>>>>> Thanks Jim.
>>>>> I tried with different optimization flags, but it doesn't make a big
>>>>> difference. Tracing it down to system calls, somehow the gl
>>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
>>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
>>>>> per invocation. The number of invocations is comparable between iOS and
>>>>> Android.
>>>>> 
>>>>> If you can give me a direction on where to search for the disabled
>>>>> scrolling optimization, I'll try to re-enable that and see how it
>>>>> improves performance. It might be a huge and quick win...
>>>>> 
>>>>> Thanks again,
>>>>> 
>>>>> - Johan
>>>>> 
>>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham <james.gra...@oracle.com
>>>>> <mailto:james.gra...@oracle.com>> wrote:
>>>>> 
>>>>>   Perhaps optimization flags with the native compiler?  Also, was it
>>>>&

Re: pisces, produceFillAlphas

[Felix Bembrick]

Johan? I really need this kind of information and you seem to be the most 
qualified person to provide it.

Cheers,

Felix

> On 31 Oct 2015, at 19:23, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> Hi Johan,
> 
> Now that your workload has hopefully lessened a bit after J1, do you think 
> you could find some time to address this question of mine from earlier?
> 
> Thanks,
> 
> Felix
> 
>> On 18 Oct 2015, at 19:01, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> 
>> Hi Johan,
>> 
>> If you have been getting acceptable but not stunning performance on Android 
>> and all this time hardware acceleration was not being utilised then it 
>> sounds like there is some serious room for some dramatic performance 
>> increases.
>> 
>> Not being that familiar with the finer points of how JavaFX is implemented 
>> on Android, just how much work is involved in accessing that hardware 
>> acceleration?  Any timeline?
>> 
>> I expect that implementing this significant change could be a make-or-break 
>> factor in determining whether JavaFX is truly viable and successful on 
>> Android.
>> 
>> Good luck Johan!
>> 
>> Cheers,
>> 
>> Felix 
>> 
>>> On 17 Oct 2015, at 19:49, Johan Vos <johan@gluonhq.com> wrote:
>>> 
>>> As a follow-up on the second part: after about 2 years working on JavaFX on
>>> Android, I discovered we are not even using Hardware Acceleration. We
>>> create a SurfaceView and render on that, but it turns out SurfaceView is
>>> never Hardware Accelerated. The positive thing is that this means there is
>>> even more room for optimization :)
>>> 
>>> - Johan
>>> 
>>>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos <johan@gluonhq.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Thanks for the suggestions. There are 2 different things:
>>>> 
>>>> 1. It seems indeed there is not much being cached, so there are definitely
>>>> improvements possible. It also require e.g. VirtualFlow to use the
>>>> Node.setCache(true) in order to cache. The combination of this with the
>>>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty
>>>> is memory, but so far, we didn't run into issues with too high GC activity.
>>>> 
>>>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
>>>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
>>>> I'll have to look into some EGL options.
>>>> 
>>>> - Johan
>>>> 
>>>> 
>>>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham <james.gra...@oracle.com>
>>>> wrote:
>>>> 
>>>>> Chien pointed out a system property that is currently disabling the
>>>>> scrolling optimization.  For its implementation look at CacheFilter.java,
>>>>> in particular the invalidateByTranslation() method and all that it kicks
>>>>> off.
>>>>> 
>>>>> Another thing to look at is that we added alpha batching to the code
>>>>> which should be batching all of the output of the produceAlphas calls into
>>>>> a texture and then drawing all of the quads together - provided that they
>>>>> are all being filled with simple colors (they can have alpha, but they
>>>>> can't be gradients, etc.).  This should be managed by the
>>>>> BaseContext.updateMaskTexture() method which controls the single batch
>>>>> texture.
>>>>> 
>>>>> Again, are there similar number of invocations of the glDrawElements on
>>>>> the 2 platforms?
>>>>> 
>>>>>  ...jim
>>>>> 
>>>>>> On 10/15/15 12:30 PM, Johan Vos wrote:
>>>>>> 
>>>>>> Thanks Jim.
>>>>>> I tried with different optimization flags, but it doesn't make a big
>>>>>> difference. Tracing it down to system calls, somehow the gl
>>>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
>>>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
>>>>>> per invocation. The number of invocations is comparable between iOS and
>>>>>> Android.
>>>>>> 
>>>>>> If you can give me a direction on where to search for the disabled
>>>>>> scrolling optimizatio

Re: pisces, produceFillAlphas

[Felix Bembrick]

Hi Johan,

Now that your workload has hopefully lessened a bit after J1, do you think you 
could find some time to address this question of mine from earlier?

Thanks,

Felix

> On 18 Oct 2015, at 19:01, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> Hi Johan,
> 
> If you have been getting acceptable but not stunning performance on Android 
> and all this time hardware acceleration was not being utilised then it sounds 
> like there is some serious room for some dramatic performance increases.
> 
> Not being that familiar with the finer points of how JavaFX is implemented on 
> Android, just how much work is involved in accessing that hardware 
> acceleration?  Any timeline?
> 
> I expect that implementing this significant change could be a make-or-break 
> factor in determining whether JavaFX is truly viable and successful on 
> Android.
> 
> Good luck Johan!
> 
> Cheers,
> 
> Felix 
> 
>> On 17 Oct 2015, at 19:49, Johan Vos <johan@gluonhq.com> wrote:
>> 
>> As a follow-up on the second part: after about 2 years working on JavaFX on
>> Android, I discovered we are not even using Hardware Acceleration. We
>> create a SurfaceView and render on that, but it turns out SurfaceView is
>> never Hardware Accelerated. The positive thing is that this means there is
>> even more room for optimization :)
>> 
>> - Johan
>> 
>>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos <johan@gluonhq.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for the suggestions. There are 2 different things:
>>> 
>>> 1. It seems indeed there is not much being cached, so there are definitely
>>> improvements possible. It also require e.g. VirtualFlow to use the
>>> Node.setCache(true) in order to cache. The combination of this with the
>>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty
>>> is memory, but so far, we didn't run into issues with too high GC activity.
>>> 
>>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
>>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
>>> I'll have to look into some EGL options.
>>> 
>>> - Johan
>>> 
>>> 
>>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham <james.gra...@oracle.com>
>>> wrote:
>>> 
>>>> Chien pointed out a system property that is currently disabling the
>>>> scrolling optimization.  For its implementation look at CacheFilter.java,
>>>> in particular the invalidateByTranslation() method and all that it kicks
>>>> off.
>>>> 
>>>> Another thing to look at is that we added alpha batching to the code
>>>> which should be batching all of the output of the produceAlphas calls into
>>>> a texture and then drawing all of the quads together - provided that they
>>>> are all being filled with simple colors (they can have alpha, but they
>>>> can't be gradients, etc.).  This should be managed by the
>>>> BaseContext.updateMaskTexture() method which controls the single batch
>>>> texture.
>>>> 
>>>> Again, are there similar number of invocations of the glDrawElements on
>>>> the 2 platforms?
>>>> 
>>>>   ...jim
>>>> 
>>>>> On 10/15/15 12:30 PM, Johan Vos wrote:
>>>>> 
>>>>> Thanks Jim.
>>>>> I tried with different optimization flags, but it doesn't make a big
>>>>> difference. Tracing it down to system calls, somehow the gl
>>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
>>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
>>>>> per invocation. The number of invocations is comparable between iOS and
>>>>> Android.
>>>>> 
>>>>> If you can give me a direction on where to search for the disabled
>>>>> scrolling optimization, I'll try to re-enable that and see how it
>>>>> improves performance. It might be a huge and quick win...
>>>>> 
>>>>> Thanks again,
>>>>> 
>>>>> - Johan
>>>>> 
>>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham <james.gra...@oracle.com
>>>>> <mailto:james.gra...@oracle.com>> wrote:
>>>>> 
>>>>>   Perhaps optimization flags with the native compiler?  Also, was it
>>>>>   called a similar number of times on both?
>

Re: Windows Hi-DPI

[Felix Bembrick]

I am using Java 8u66 and performance is really poor.

I suspected a driver issue but I have the latest driver for my Titan X card (4 
in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in 
the top 1% fastest computers ever to run the tests.

It looks to me that JavaFX just can't deliver acceptable performance on 4K 
monitors, even with the most powerful graphics cards on the planet. Or maybe it 
doesn't support SLI?

It could be Windows 10 related but I don't think so. And I am definitely 
getting hardware acceleration according to the output so I suspect JavaFX has 
trouble moving so many pixels around on these hi-res monitors.

All other 3D apps and games run blindingly fast but JavaFX actually runs slower 
on this beast than on my wife's little i5 powered Dell machine with a low range 
graphics card, also running Windows 10.

Any ideas?

Felix

> On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote:
> 
> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 
> or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 
> with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in 
> this case with the Intel 4600 integrated GPU.
> 
> However, this causes frequent Intel display driver crashes and restarts 
> because the Windows 10 drivers are still so immature. Same happens in WPF 
> applications, so it's not specific to JavaFX. I've grabbed my driver directly 
> from the Intel website. Possibly your system runs an older driver that causes 
> JavaFX not to use HA.
> 
> Given how unstable it currently is on Windows 10, that might not be a bad 
> idea. But of course you could try manually updating and see what happens to 
> JavaFX performance.
> 
> Cheers, Chris
> 
> 
>> On 2015-10-28 17:24:38, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> I just installed JavaFX on my new Windows 10 machine which is extremely 
>> powerful but has two 4K monitors and while everything looks great and the 
>> right "size", the performance is very sluggish to say the least.
>> 
>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>> 
>> Thanks,
>> 
>> Fix
> 

Re: Windows Hi-DPI

[Felix Bembrick]

That's curious. SLI is designed specifically with gamers in mind!

I'll investigating running without SLI and report back.

Felix 

> On 30 Oct 2015, at 19:44, Chris Nahr <chris.n...@gmail.com> wrote:
> 
> If it's slower on an SLI machine than on an ordinary one then yes, I suspect 
> JavaFX just can't handle SLI properly. Among gamers I've often heard that 
> it's a notoriously problematic configuration. Can you switch your card to 
> non-SLI mode and retest performance?
> 
> --Chris
> 
>> On 2015-10-30 09:19, Felix Bembrick wrote:
>> I am using Java 8u66 and performance is really poor.
>> 
>> I suspected a driver issue but I have the latest driver for my Titan X card 
>> (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine 
>> is in the top 1% fastest computers ever to run the tests.
>> 
>> It looks to me that JavaFX just can't deliver acceptable performance on 4K 
>> monitors, even with the most powerful graphics cards on the planet. Or maybe 
>> it doesn't support SLI?
>> 
>> It could be Windows 10 related but I don't think so. And I am definitely 
>> getting hardware acceleration according to the output so I suspect JavaFX 
>> has trouble moving so many pixels around on these hi-res monitors.
>> 
>> All other 3D apps and games run blindingly fast but JavaFX actually runs 
>> slower on this beast than on my wife's little i5 powered Dell machine with a 
>> low range graphics card, also running Windows 10.
>> 
>> Any ideas?
>> 
>> Felix
>> 
>>> On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote:
>>> 
>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 
>>> 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell 
>>> XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware 
>>> acceleration, in this case with the Intel 4600 integrated GPU.
>>> 
>>> However, this causes frequent Intel display driver crashes and restarts 
>>> because the Windows 10 drivers are still so immature. Same happens in WPF 
>>> applications, so it's not specific to JavaFX. I've grabbed my driver 
>>> directly from the Intel website. Possibly your system runs an older driver 
>>> that causes JavaFX not to use HA.
>>> 
>>> Given how unstable it currently is on Windows 10, that might not be a bad 
>>> idea. But of course you could try manually updating and see what happens to 
>>> JavaFX performance.
>>> 
>>> Cheers, Chris
>>> 
>>> 
>>>> On 2015-10-28 17:24:38, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>>> I just installed JavaFX on my new Windows 10 machine which is extremely 
>>>> powerful but has two 4K monitors and while everything looks great and the 
>>>> right "size", the performance is very sluggish to say the least.
>>>> 
>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>>>> 
>>>> Thanks,
>>>> 
>>>> Fix
>>> 

Re: Windows Hi-DPI

[Felix Bembrick]

Yes, but unless you are saying that having more cores, more VRAM, faster VRAM 
and a much faster clock speed are actually going to slow down the performance 
of JavaFX then I don't know what point you are trying to make.

> On 31 Oct 2015, at 01:03, Bogdan Ibanescu <bibane...@montran.com> wrote:
> 
> Having 200 cores won't help you with anything unless you explicitly customize 
> your code to make use of them.
> 
> - Original Message -
> From: "Felix Bembrick" <felix.bembr...@gmail.com>
> To: "Chris Nahr" <chris.n...@gmail.com>
> Cc: openjfx-dev@openjdk.java.net
> Sent: Friday, October 30, 2015 11:55:19 AM
> Subject: Re: Windows Hi-DPI
> 
> The NVIDIA Control Panel allowed me to disable SLI completely and I even 
> rebooted.  I also upgraded to Java 8u72.
> 
> Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a 
> chain.
> 
> All other 3D apps, games etc. perform blindingly fast as I would expect.
> 
> So, if it's not an SLI or driver problem, what is going on here (or not going 
> on)?
> 
> Felix
> 
>> On 30 Oct 2015, at 19:47, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>> 
>> That's curious. SLI is designed specifically with gamers in mind!
>> 
>> I'll investigating running without SLI and report back.
>> 
>> Felix 
>> 
>>> On 30 Oct 2015, at 19:44, Chris Nahr <chris.n...@gmail.com> wrote:
>>> 
>>> If it's slower on an SLI machine than on an ordinary one then yes, I 
>>> suspect JavaFX just can't handle SLI properly. Among gamers I've often 
>>> heard that it's a notoriously problematic configuration. Can you switch 
>>> your card to non-SLI mode and retest performance?
>>> 
>>> --Chris
>>> 
>>>> On 2015-10-30 09:19, Felix Bembrick wrote:
>>>> I am using Java 8u66 and performance is really poor.
>>>> 
>>>> I suspected a driver issue but I have the latest driver for my Titan X 
>>>> card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my 
>>>> machine is in the top 1% fastest computers ever to run the tests.
>>>> 
>>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K 
>>>> monitors, even with the most powerful graphics cards on the planet. Or 
>>>> maybe it doesn't support SLI?
>>>> 
>>>> It could be Windows 10 related but I don't think so. And I am definitely 
>>>> getting hardware acceleration according to the output so I suspect JavaFX 
>>>> has trouble moving so many pixels around on these hi-res monitors.
>>>> 
>>>> All other 3D apps and games run blindingly fast but JavaFX actually runs 
>>>> slower on this beast than on my wife's little i5 powered Dell machine with 
>>>> a low range graphics card, also running Windows 10.
>>>> 
>>>> Any ideas?
>>>> 
>>>> Felix
>>>> 
>>>>> On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote:
>>>>> 
>>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 
>>>>> 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell 
>>>>> XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware 
>>>>> acceleration, in this case with the Intel 4600 integrated GPU.
>>>>> 
>>>>> However, this causes frequent Intel display driver crashes and restarts 
>>>>> because the Windows 10 drivers are still so immature. Same happens in WPF 
>>>>> applications, so it's not specific to JavaFX. I've grabbed my driver 
>>>>> directly from the Intel website. Possibly your system runs an older 
>>>>> driver that causes JavaFX not to use HA.
>>>>> 
>>>>> Given how unstable it currently is on Windows 10, that might not be a bad 
>>>>> idea. But of course you could try manually updating and see what happens 
>>>>> to JavaFX performance.
>>>>> 
>>>>> Cheers, Chris
>>>>> 
>>>>> 
>>>>>> On 2015-10-28 17:24:38, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely 
>>>>>> powerful but has two 4K monitors and while everything looks great and 
>>>>>> the right "size", the performance is very sluggish to say the least.
>>>>>> 
>>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Fix
>>>>> 
> 
> -- 
> Best Regards, 
> -- Bogdan Marius Ibanescu 
> -- Montran Corporation - Branch of Cluj-Napoca 
> 

Re: Windows Hi-DPI

[Felix Bembrick]

Thanks Bogdan, but that "poor code" works extremely well everywhere else.

> On 31 Oct 2015, at 03:56, Bogdan Ibanescu <bibane...@montran.com> wrote:
> 
> The point I'm trying to make is that if you're running a single threaded 
> application, it'll use 1 core.
> 
> What you need to understand is that javafx does not magically figure out how 
> organize rendering procedures across the systems' resources.
> 
> The reason for which whatever you're trying to test seems to be about as fast 
> on your computer as it is on your wife's' is because it's most likely not 
> multi-threaded, or plainly badly implemented.
> Cross-fire and SLI and all that other crap is useless if you're only using 1% 
> of your resources. All windows does when you select the GPU is the driver 
> end-point. Activating it makes it run slightly faster because of the 
> differences in hardware... but the lack of performance is the poor code in 
> your software.
> 
> - Original Message -
> From: "Felix Bembrick" <felix.bembr...@gmail.com>
> To: "Bogdan Ibanescu" <bibane...@montran.com>
> Cc: "Chris Nahr" <chris.n...@gmail.com>, openjfx-dev@openjdk.java.net
> Sent: Friday, October 30, 2015 5:37:35 PM
> Subject: Re: Windows Hi-DPI
> 
> Yes, but unless you are saying that having more cores, more VRAM, faster VRAM 
> and a much faster clock speed are actually going to slow down the performance 
> of JavaFX then I don't know what point you are trying to make.
> 
>> On 31 Oct 2015, at 01:03, Bogdan Ibanescu <bibane...@montran.com> wrote:
>> 
>> Having 200 cores won't help you with anything unless you explicitly 
>> customize your code to make use of them.
>> 
>> - Original Message -
>> From: "Felix Bembrick" <felix.bembr...@gmail.com>
>> To: "Chris Nahr" <chris.n...@gmail.com>
>> Cc: openjfx-dev@openjdk.java.net
>> Sent: Friday, October 30, 2015 11:55:19 AM
>> Subject: Re: Windows Hi-DPI
>> 
>> The NVIDIA Control Panel allowed me to disable SLI completely and I even 
>> rebooted.  I also upgraded to Java 8u72.
>> 
>> Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on 
>> a chain.
>> 
>> All other 3D apps, games etc. perform blindingly fast as I would expect.
>> 
>> So, if it's not an SLI or driver problem, what is going on here (or not 
>> going on)?
>> 
>> Felix
>> 
>>> On 30 Oct 2015, at 19:47, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>> 
>>> That's curious. SLI is designed specifically with gamers in mind!
>>> 
>>> I'll investigating running without SLI and report back.
>>> 
>>> Felix 
>>> 
>>>> On 30 Oct 2015, at 19:44, Chris Nahr <chris.n...@gmail.com> wrote:
>>>> 
>>>> If it's slower on an SLI machine than on an ordinary one then yes, I 
>>>> suspect JavaFX just can't handle SLI properly. Among gamers I've often 
>>>> heard that it's a notoriously problematic configuration. Can you switch 
>>>> your card to non-SLI mode and retest performance?
>>>> 
>>>> --Chris
>>>> 
>>>>> On 2015-10-30 09:19, Felix Bembrick wrote:
>>>>> I am using Java 8u66 and performance is really poor.
>>>>> 
>>>>> I suspected a driver issue but I have the latest driver for my Titan X 
>>>>> card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my 
>>>>> machine is in the top 1% fastest computers ever to run the tests.
>>>>> 
>>>>> It looks to me that JavaFX just can't deliver acceptable performance on 
>>>>> 4K monitors, even with the most powerful graphics cards on the planet. Or 
>>>>> maybe it doesn't support SLI?
>>>>> 
>>>>> It could be Windows 10 related but I don't think so. And I am definitely 
>>>>> getting hardware acceleration according to the output so I suspect JavaFX 
>>>>> has trouble moving so many pixels around on these hi-res monitors.
>>>>> 
>>>>> All other 3D apps and games run blindingly fast but JavaFX actually runs 
>>>>> slower on this beast than on my wife's little i5 powered Dell machine 
>>>>> with a low range graphics card, also running Windows 10.
>>>>> 
>>>>> Any ideas?
>>>>> 
>>>>> Felix
>>>>> 
>>>>>> On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote:
>>>>

Re: Windows Hi-DPI

[Felix Bembrick]

Hi Jim,

I had Windows 10 on my previous machine and my wife's low-end PC is also 
running Win10 and the same version of Java.

But I have what is supposed to be the fastest graphics card of all (GeForce GTX 
Titan X) and she has a very basic card.

The only real difference is that she has a 22" monitor with a resolution of 
1920 X 1024 (?) and I have 2 4K monitors.

Hi-DPI is supported in the sense that everything renders at the correct size 
etc (unlike Swing) but it performs so slowly that there must be something 
fundamentally wrong, especially since JavaFX seems to be the only technology 
that's affected.

> On 31 Oct 2015, at 06:49, Jim Graham <james.gra...@oracle.com> wrote:
> 
> It should be supported.  Which version of Windows were you using before?  
> We've supported HiDPI on Windows since JDK8u60 on all supported versions of 
> Windows...
> 
>...jim
> 
>> On 10/27/15 11:24 PM, Felix Bembrick wrote:
>> I just installed JavaFX on my new Windows 10 machine which is extremely 
>> powerful but has two 4K monitors and while everything looks great and the 
>> right "size", the performance is very sluggish to say the least.
>> 
>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>> 
>> Thanks,
>> 
>> Fix
>> 

Re: Windows Hi-DPI

[Felix Bembrick]

Hi Jim,

I have experimented with all those options with the following results:

1. Turning on verbose proves hardware acceleration is being used.
2. Increasing texture size and fiddling with the amount of VRAM has no
effect on performance.
3. Turning off Hi DPI changes the appearance of the app (i.e. controls
are too small etc.) but has no effect on performance.
4. Disabling hardware acceleration makes it another order of magnitude
slower than before.

So none of the options improved performance at all.  All we know for sure
is that it's using D3D and that it is running so much slower than I
expected and so much so that it is unusable.

Here's some of the initial output which hopefully shows something about the
issue:



























*Prism pipeline init order: d3dUsing native-based Pisces rasterizerUsing
dirty region optimizationsNot using texture mask for primitivesNot forcing
power of 2 sizes for texturesUsing hardware CLAMP_TO_ZERO modeOpting in for
HiDPI pixel scalingPrism pipeline name =
com.sun.prism.d3d.D3DPipelineLoading D3D native library ...
succeeded.D3DPipelineManager: Created D3D9Ex deviceDirect3D initialization
succeeded(X) Got class = class com.sun.prism.d3d.D3DPipelineInitialized
prism pipeline: com.sun.prism.d3d.D3DPipelineMaximum supported texture
size: 16384Maximum texture size clamped to 8192OS Information:
Windows version 10.0 build 10240D3D Driver Information:NVIDIA
GeForce GTX TITAN X\\.\DISPLAY1Driver nvd3dum.dll, version
10.18.13.5850Pixel Shader version 3.0Device : ven_10DE,
dev_17C2, subsys_113210DEMax Multisamples supported: 4 vsync: true
vpipe: trueLoading Prism common native library ...*






*succeeded.PPSRenderer: scenario.effect - createShader:
LinearConvolveShadow_28PPSRenderer: scenario.effect - createShader:
LinearConvolve_8PPSRenderer: scenario.effect - createShader:
LinearConvolve_64PPSRenderer: scenario.effect - createShader:
Blend_ADDPPSRenderer: scenario.effect - createShader:
LinearConvolveShadow_16PPSRenderer: scenario.effect - createShader:
LinearConvolve_12*

-

On 31 October 2015 at 07:21, Jim Graham <james.gra...@oracle.com> wrote:

> Other things to try:
>
> -Dprism.verbose=true  (output should show the following options
> are working)
>
> -Dglass.win.uiScale=1.0   (disables HiDPI)
> -Dprism.order=sw  (disables HW acceleration)
> -Dprism.maxTextureSize=8192   (mentioned before - increases max texture
> dims)
>
> -Dprism.maxvram=2G(increases maximum texture pool to 2GB)
> -Dprism.targetvram=2G (combined with maxvram, increases initial
> pool to 2GB)
>
>     ...jim
>
>
> On 10/30/15 12:59 PM, Felix Bembrick wrote:
>
>> Hi Jim,
>>
>> I had Windows 10 on my previous machine and my wife's low-end PC is also
>> running Win10 and the same version of Java.
>>
>> But I have what is supposed to be the fastest graphics card of all
>> (GeForce GTX Titan X) and she has a very basic card.
>>
>> The only real difference is that she has a 22" monitor with a resolution
>> of 1920 X 1024 (?) and I have 2 4K monitors.
>>
>> Hi-DPI is supported in the sense that everything renders at the correct
>> size etc (unlike Swing) but it performs so slowly that there must be
>> something fundamentally wrong, especially since JavaFX seems to be the only
>> technology that's affected.
>>
>> On 31 Oct 2015, at 06:49, Jim Graham <james.gra...@oracle.com> wrote:
>>>
>>> It should be supported.  Which version of Windows were you using
>>> before?  We've supported HiDPI on Windows since JDK8u60 on all supported
>>> versions of Windows...
>>>
>>> ...jim
>>>
>>> On 10/27/15 11:24 PM, Felix Bembrick wrote:
>>>> I just installed JavaFX on my new Windows 10 machine which is extremely
>>>> powerful but has two 4K monitors and while everything looks great and the
>>>> right "size", the performance is very sluggish to say the least.
>>>>
>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>>>>
>>>> Thanks,
>>>>
>>>> Fix
>>>>
>>>>

Re: Windows Hi-DPI

[Felix Bembrick]

The NVIDIA Control Panel allowed me to disable SLI completely and I even 
rebooted.  I also upgraded to Java 8u72.

Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a 
chain.

All other 3D apps, games etc. perform blindingly fast as I would expect.

So, if it's not an SLI or driver problem, what is going on here (or not going 
on)?

Felix

> On 30 Oct 2015, at 19:47, Felix Bembrick <felix.bembr...@gmail.com> wrote:
> 
> That's curious. SLI is designed specifically with gamers in mind!
> 
> I'll investigating running without SLI and report back.
> 
> Felix 
> 
>> On 30 Oct 2015, at 19:44, Chris Nahr <chris.n...@gmail.com> wrote:
>> 
>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect 
>> JavaFX just can't handle SLI properly. Among gamers I've often heard that 
>> it's a notoriously problematic configuration. Can you switch your card to 
>> non-SLI mode and retest performance?
>> 
>> --Chris
>> 
>>> On 2015-10-30 09:19, Felix Bembrick wrote:
>>> I am using Java 8u66 and performance is really poor.
>>> 
>>> I suspected a driver issue but I have the latest driver for my Titan X card 
>>> (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine 
>>> is in the top 1% fastest computers ever to run the tests.
>>> 
>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K 
>>> monitors, even with the most powerful graphics cards on the planet. Or 
>>> maybe it doesn't support SLI?
>>> 
>>> It could be Windows 10 related but I don't think so. And I am definitely 
>>> getting hardware acceleration according to the output so I suspect JavaFX 
>>> has trouble moving so many pixels around on these hi-res monitors.
>>> 
>>> All other 3D apps and games run blindingly fast but JavaFX actually runs 
>>> slower on this beast than on my wife's little i5 powered Dell machine with 
>>> a low range graphics card, also running Windows 10.
>>> 
>>> Any ideas?
>>> 
>>> Felix
>>> 
>>>> On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote:
>>>> 
>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 
>>>> 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell 
>>>> XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware 
>>>> acceleration, in this case with the Intel 4600 integrated GPU.
>>>> 
>>>> However, this causes frequent Intel display driver crashes and restarts 
>>>> because the Windows 10 drivers are still so immature. Same happens in WPF 
>>>> applications, so it's not specific to JavaFX. I've grabbed my driver 
>>>> directly from the Intel website. Possibly your system runs an older driver 
>>>> that causes JavaFX not to use HA.
>>>> 
>>>> Given how unstable it currently is on Windows 10, that might not be a bad 
>>>> idea. But of course you could try manually updating and see what happens 
>>>> to JavaFX performance.
>>>> 
>>>> Cheers, Chris
>>>> 
>>>> 
>>>>> On 2015-10-28 17:24:38, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely 
>>>>> powerful but has two 4K monitors and while everything looks great and the 
>>>>> right "size", the performance is very sluggish to say the least.
>>>>> 
>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Fix
>>>> 

Windows Hi-DPI

[Felix Bembrick]

I just installed JavaFX on my new Windows 10 machine which is extremely 
powerful but has two 4K monitors and while everything looks great and the right 
"size", the performance is very sluggish to say the least.

Is this because Hi-DPI is not yet supported in JavaFX on Windows?

Thanks,

Fix

Re: pisces, produceFillAlphas

[Felix Bembrick]

Hi Johan,

If you have been getting acceptable but not stunning performance on Android and 
all this time hardware acceleration was not being utilised then it sounds like 
there is some serious room for some dramatic performance increases.

Not being that familiar with the finer points of how JavaFX is implemented on 
Android, just how much work is involved in accessing that hardware 
acceleration?  Any timeline?

I expect that implementing this significant change could be a make-or-break 
factor in determining whether JavaFX is truly viable and successful on Android.

Good luck Johan!

Cheers,

Felix 

> On 17 Oct 2015, at 19:49, Johan Vos  wrote:
> 
> As a follow-up on the second part: after about 2 years working on JavaFX on
> Android, I discovered we are not even using Hardware Acceleration. We
> create a SurfaceView and render on that, but it turns out SurfaceView is
> never Hardware Accelerated. The positive thing is that this means there is
> even more room for optimization :)
> 
> - Johan
> 
>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos  wrote:
>> 
>> Hi,
>> 
>> Thanks for the suggestions. There are 2 different things:
>> 
>> 1. It seems indeed there is not much being cached, so there are definitely
>> improvements possible. It also require e.g. VirtualFlow to use the
>> Node.setCache(true) in order to cache. The combination of this with the
>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty
>> is memory, but so far, we didn't run into issues with too high GC activity.
>> 
>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
>> I'll have to look into some EGL options.
>> 
>> - Johan
>> 
>> 
>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham 
>> wrote:
>> 
>>> Chien pointed out a system property that is currently disabling the
>>> scrolling optimization.  For its implementation look at CacheFilter.java,
>>> in particular the invalidateByTranslation() method and all that it kicks
>>> off.
>>> 
>>> Another thing to look at is that we added alpha batching to the code
>>> which should be batching all of the output of the produceAlphas calls into
>>> a texture and then drawing all of the quads together - provided that they
>>> are all being filled with simple colors (they can have alpha, but they
>>> can't be gradients, etc.).  This should be managed by the
>>> BaseContext.updateMaskTexture() method which controls the single batch
>>> texture.
>>> 
>>> Again, are there similar number of invocations of the glDrawElements on
>>> the 2 platforms?
>>> 
>>>...jim
>>> 
 On 10/15/15 12:30 PM, Johan Vos wrote:
 
 Thanks Jim.
 I tried with different optimization flags, but it doesn't make a big
 difference. Tracing it down to system calls, somehow the gl
 implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
 * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
 per invocation. The number of invocations is comparable between iOS and
 Android.
 
 If you can give me a direction on where to search for the disabled
 scrolling optimization, I'll try to re-enable that and see how it
 improves performance. It might be a huge and quick win...
 
 Thanks again,
 
 - Johan
 
 On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > wrote:
 
Perhaps optimization flags with the native compiler?  Also, was it
called a similar number of times on both?
 
Ideally we'd just be using copyArea for the scrolling, but at one
point we disabled the scrolling optimizations on retina MBP because
they didn't work with a scale factor and I don't think we reenabled
them yet.  That would kill scrolling performance on mobile as a
result of having to rerender the scene on each scroll regardless of
how long produceAlphas takes...
 
 ...jim
 
 
On 10/15/15 4:27 AM, Johan Vos wrote:
 
After spending lots of time optimizing JavaFX on iOS, I am now
at the point
where scrolling is 10 times faster on iOS than on Android.
The scrolling in the iOS version of the Gluon JavaOne mobile
schedule
builder is pretty good imho. On Android, it is much slower. I
profiled and
compared both, and it turns out that on Android, we spend lots
of time in
the native implementation of
NativePiscesRasterizer.produceFillAlphas
(implemented in native-prism/NativePiscesRasterizer.c)
 
On average, calling this native function on an iPhone 6 takes
40,000ns
whereas on a Nexus 6, this takes 

Java & JavaFX on mobiles

[Felix Bembrick]

The world of Java and JavaFX is growing more confusing than ever it seems.

Some say Oracle is cutting back on funding for Java because it is effectively 
helping its competitors. Sounds similar to Google forking WebKit so they 
weren't writing code for Apple.

But now we hear of the looming release of official JDKs for iOS and Android 
from Oracle.

Will these JDKs be the best and simplest way of running JavaFX on those 
platforms? Without JIT support, will these JDKs support AOT compiling?

Do the proposed JDKs for mobiles even include JavaFX?

Felix

Re: Java & JavaFX on mobiles

[Felix Bembrick]

What would be the reason/logic for not including JavaFX in these JDKs?

> On 8 Oct 2015, at 08:19, Steve Hannah <st...@weblite.ca> wrote:
> 
> I recall reading that these JDKs won't include any UI components.  Since iOS 
> doesn't support JIT, the iOS port of JDK will certainly be AOT compiling.
> 
>> On Wed, Oct 7, 2015 at 2:11 PM, Felix Bembrick <felix.bembr...@gmail.com> 
>> wrote:
>> The world of Java and JavaFX is growing more confusing than ever it seems.
>> 
>> Some say Oracle is cutting back on funding for Java because it is 
>> effectively helping its competitors. Sounds similar to Google forking WebKit 
>> so they weren't writing code for Apple.
>> 
>> But now we hear of the looming release of official JDKs for iOS and Android 
>> from Oracle.
>> 
>> Will these JDKs be the best and simplest way of running JavaFX on those 
>> platforms? Without JIT support, will these JDKs support AOT compiling?
>> 
>> Do the proposed JDKs for mobiles even include JavaFX?
>> 
>> Felix
> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.

More fun with layered icons in javaFX - GuiGarage

[Felix Bembrick]

http://www.guigarage.com/2015/09/more-fun-with-layered-icons-in-javafx/

Re: Goodbye, so long, auf wiedersehen, adieu

[Felix Bembrick]

Sorry for spamming the entire list.  It was meant as a personal message to
Mark but GMail seemed to want everyone to see it when I selected reply.

Felix

On 3 September 2015 at 07:08, Felix Bembrick <felix.bembr...@gmail.com>
wrote:

> Hi Mark,
>
> I am not sure if this is good news or bad news but it sounds like you were
> made redundant which would of course be bad news.  Oracle seem quite whacky
> lately with the things they are doing and the people they are letting go.
>
> Anyway, sorry for your bad news but the exact same thing happened to me
> last year so I formed my own business and now have much more time to focus
> on the technologies I like and write my music.  I haven't looked back and
> don't think I will ever have a boss again.
>
> So where to now?  Anything lined up or on the horizon?
>
> I am sure you will find something very quickly and with your skill and
> experience, it will be a good position with appropriate remuneration.
>
> I'd like to stay in touch.  We still have Facebook anyway!
>
> All the best for the future and God Bless,
>
> Felix
>
> P.S. How is Jennifer doing?
>
>
> On 3 September 2015 at 05:38, Mark Heckler <mark.heck...@oracle.com>
> wrote:
>
>> All,
>>
>>
>>
>> It has been a pleasure and honor to have worked with you. I am among
>> those whose positions were eliminated suddenly (today!), so I'll be
>> exploring other opportunities. If you're receiving this email, I'd like
>> very much to stay in touch with you! My personal contact information
>> follows:
>>
>>
>>
>> HYPERLINK "mailto:mark.heck...@gmail.com"mark.heck...@gmail.com
>>
>> HYPERLINK "mailto:m...@thehecklers.org"m...@thehecklers.org
>>
>> GVoice phone: 618-215-6275
>>
>> LinkedIn: https://www.linkedin.com/in/markheckler
>>
>>
>>
>> Areas of particular expertise include Java (SE Embedded through EE),
>> DevOps, PaaS development, and especially evangelism/advocacy of same.
>>
>>
>>
>> Please let me know if you know of any opportunities; I'm willing to
>> listen. :)
>>
>>
>>
>> Wishing you all the best,
>> Mark
>>
>> /*
>>
>>   Mark A. Heckler, MBA
>>
>>   Developer Evangelist
>>
>>   Oracle Cloud Developer Program
>>
>>   Oracle Corporation
>>
>>   618.799.9985 cell
>>
>>   HYPERLINK "mailto:mark.heck...@oracle.com"mark.heck...@oracle.com
>>
>>
>>
>>   Any opinions that I have expressed in this email are mine and do not
>>
>>   necessarily reflect those of Oracle.
>>
>>
>>
>>   Todas las opiniones que haya expresado en este email son las mías y
>>
>>   no reflejan necesariamente las de Oracle.
>>
>> */
>>
>>
>>
>
>

Re: Goodbye, so long, auf wiedersehen, adieu

[Felix Bembrick]

Hi Mark,

I am not sure if this is good news or bad news but it sounds like you were
made redundant which would of course be bad news.  Oracle seem quite whacky
lately with the things they are doing and the people they are letting go.

Anyway, sorry for your bad news but the exact same thing happened to me
last year so I formed my own business and now have much more time to focus
on the technologies I like and write my music.  I haven't looked back and
don't think I will ever have a boss again.

So where to now?  Anything lined up or on the horizon?

I am sure you will find something very quickly and with your skill and
experience, it will be a good position with appropriate remuneration.

I'd like to stay in touch.  We still have Facebook anyway!

All the best for the future and God Bless,

Felix

P.S. How is Jennifer doing?


On 3 September 2015 at 05:38, Mark Heckler  wrote:

> All,
>
>
>
> It has been a pleasure and honor to have worked with you. I am among those
> whose positions were eliminated suddenly (today!), so I'll be exploring
> other opportunities. If you're receiving this email, I'd like very much to
> stay in touch with you! My personal contact information follows:
>
>
>
> HYPERLINK "mailto:mark.heck...@gmail.com"mark.heck...@gmail.com
>
> HYPERLINK "mailto:m...@thehecklers.org"m...@thehecklers.org
>
> GVoice phone: 618-215-6275
>
> LinkedIn: https://www.linkedin.com/in/markheckler
>
>
>
> Areas of particular expertise include Java (SE Embedded through EE),
> DevOps, PaaS development, and especially evangelism/advocacy of same.
>
>
>
> Please let me know if you know of any opportunities; I'm willing to
> listen. :)
>
>
>
> Wishing you all the best,
> Mark
>
> /*
>
>   Mark A. Heckler, MBA
>
>   Developer Evangelist
>
>   Oracle Cloud Developer Program
>
>   Oracle Corporation
>
>   618.799.9985 cell
>
>   HYPERLINK "mailto:mark.heck...@oracle.com"mark.heck...@oracle.com
>
>
>
>   Any opinions that I have expressed in this email are mine and do not
>
>   necessarily reflect those of Oracle.
>
>
>
>   Todas las opiniones que haya expresado en este email son las mías y
>
>   no reflejan necesariamente las de Oracle.
>
> */
>
>
>

Re: JavaFX features in JDK 9

[Felix Bembrick]

To be fair Jack, WORA is/was used in reference to the Java language itself;
not JavaFX.

Felix

On 30 June 2015 at 17:12, Jack Moxley j...@moxley.co.uk wrote:

 coughwrite once, run anywhere/cough

 Sent from my iPhone

  On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl
 wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Does it mean platform support for linux won't be implemented now, or
  at all?
  I usually use windows, but still depend on that support because I
  sometimes use linux, so I am interested about that.
 
  W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze:
  There is public API in 8u40 to support accessibility. Applications
  using standard JavaFX controls can, for example, use the
  accessibleText property to define the text that the screen reader
  will speak or the accessibleHelp property to provide a more
  detailed description. These properties have reasonable defaults,
  but can be overridden by applications. Additionally, if you use the
  labelFor property to point to a Control that the Label is
  associated with, the accessibility framework will use that when the
  screen reader is active.
 
  Custom controls can override the queryAccessibleAttribute,
  executeAccessibleAction, and notifyAccessibleAttributeChanged
  methods.
 
  As for platform support, we currently support Windows and Mac
  platforms. We have no plan to make FX accessible on Linux .
 
  -- Kevin
 
 
  Michał Zegan wrote: I saw it, and it seems promising, but: first,
  there is probably, or I heard it wrong? no public api for making
  accessibility related stuff... Also, I believe there is no linux
  accessibility bridge as opposed to windows and mac. And I do not
  know if I am wrong, or when this is going to be implemented.
 
  W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze:
 
  JavaFX accessibility is already implemented and was delivered
  in JDK 8u40.
 
  -- Kevin
 
 
  Michał Zegan wrote: What about accessibility work? Work on it
  has been started, but not sure if it is still targetted for
  9.
 
  W dniu 2015-06-27 o 20:16, Mike pisze:
 
 
  a lot of FULL blown Webrtc support and building
  something in Javafx (like Scene Builder) that Proves
  Webrtc support would be awesome. Ditto to Webgl
  support.
 
  On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth
  kevin.rushfo...@oracle.com
 
 
  wrote:
 
  Hi Felix,
 
  Sorry for the delay. Most of us were still pretty
  focused on 8u60, but we are turning our attention to
  JDK 9 now.
 
  The focus for JDK 9 is Jigsaw. The currently planned
  big features (JEPs) for FX in JDK 9 are these:
 
  JEP 253: Prepare JavaFX UI Controls  CSS APIs for
  Modularization JEP 257: Update JavaFX/Media to Newer
  Version of GStreamer
 
  Related to Jigasw, we intend to look into new API for
  heavily used internal methods / classes since they
  will no longer be accessible otherwise. We also plan
  to update WebKit at least one more time, and will
  likely do a few RFEs such as better Hi-DPI support
  (with API control) on Mac, Windows, Linux.
 
  We don't currently plan any other big features for 9,
  but will consider additional RFEs if they are
  important to enough developers and if they fit into
  the time frame.
 
  -- Kevin
 
 
 
  Felix Bembrick wrote:
 
 
 
  Anyone got anything or is there a link somewhere
  that talks about these?
 
  On 15 June 2015 at 22:00, Felix Bembrick
  felix.bembr...@gmail.com wrote:
 
 
 
 
 
  I realise we are a long way off JDK 9 still and
  with crucial features such as Jigsaw still a
  little up in the air but is it possible someone
  could itemise the most likely new features,
  enhancements and bug fixes that we will see in
  JavaFX when JDK 9 is released?
 
  Of course it's purely speculation at this point
  but it would assist me greatly to have some of
  idea of where JavaFX is heading and which areas
  are seen as most important.
 
  Thanks,
 
  Felix
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v2
 
  iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3
  5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4
  92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf
  hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF
  JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm
  RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow
  BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1
  EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS
  eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB
  reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ
  mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii
  Mfj0LIA1IawOjtYjlnHz
  =lXSV
  -END PGP SIGNATURE-

Re: JavaFX features in JDK 9

[Felix Bembrick]

coughJavaFX has *never* claimed to be write once, run anyway/cough


 On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote:
 
 coughwrite once, run anywhere/cough
 
 This about sums it up!
 
 
 
 On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk wrote:
 
 coughwrite once, run anywhere/cough
 
 Sent from my iPhone
 
 On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Does it mean platform support for linux won't be implemented now, or
 at all?
 I usually use windows, but still depend on that support because I
 sometimes use linux, so I am interested about that.
 
 W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze:
 There is public API in 8u40 to support accessibility. Applications
 using standard JavaFX controls can, for example, use the
 accessibleText property to define the text that the screen reader
 will speak or the accessibleHelp property to provide a more
 detailed description. These properties have reasonable defaults,
 but can be overridden by applications. Additionally, if you use the
 labelFor property to point to a Control that the Label is
 associated with, the accessibility framework will use that when the
 screen reader is active.
 
 Custom controls can override the queryAccessibleAttribute,
 executeAccessibleAction, and notifyAccessibleAttributeChanged
 methods.
 
 As for platform support, we currently support Windows and Mac
 platforms. We have no plan to make FX accessible on Linux .
 
 -- Kevin
 
 
 Michał Zegan wrote: I saw it, and it seems promising, but: first,
 there is probably, or I heard it wrong? no public api for making
 accessibility related stuff... Also, I believe there is no linux
 accessibility bridge as opposed to windows and mac. And I do not
 know if I am wrong, or when this is going to be implemented.
 
 W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze:
 
 JavaFX accessibility is already implemented and was delivered
 in JDK 8u40.
 
 -- Kevin
 
 
 Michał Zegan wrote: What about accessibility work? Work on it
 has been started, but not sure if it is still targetted for
 9.
 
 W dniu 2015-06-27 o 20:16, Mike pisze:
 
 
 a lot of FULL blown Webrtc support and building
 something in Javafx (like Scene Builder) that Proves
 Webrtc support would be awesome. Ditto to Webgl
 support.
 
 On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth
 kevin.rushfo...@oracle.com
 
 
 wrote:
 
 Hi Felix,
 
 Sorry for the delay. Most of us were still pretty
 focused on 8u60, but we are turning our attention to
 JDK 9 now.
 
 The focus for JDK 9 is Jigsaw. The currently planned
 big features (JEPs) for FX in JDK 9 are these:
 
 JEP 253: Prepare JavaFX UI Controls  CSS APIs for
 Modularization JEP 257: Update JavaFX/Media to Newer
 Version of GStreamer
 
 Related to Jigasw, we intend to look into new API for
 heavily used internal methods / classes since they
 will no longer be accessible otherwise. We also plan
 to update WebKit at least one more time, and will
 likely do a few RFEs such as better Hi-DPI support
 (with API control) on Mac, Windows, Linux.
 
 We don't currently plan any other big features for 9,
 but will consider additional RFEs if they are
 important to enough developers and if they fit into
 the time frame.
 
 -- Kevin
 
 
 
 Felix Bembrick wrote:
 
 
 
 Anyone got anything or is there a link somewhere
 that talks about these?
 
 On 15 June 2015 at 22:00, Felix Bembrick
 felix.bembr...@gmail.com wrote:
 
 
 
 
 
 I realise we are a long way off JDK 9 still and
 with crucial features such as Jigsaw still a
 little up in the air but is it possible someone
 could itemise the most likely new features,
 enhancements and bug fixes that we will see in
 JavaFX when JDK 9 is released?
 
 Of course it's purely speculation at this point
 but it would assist me greatly to have some of
 idea of where JavaFX is heading and which areas
 are seen as most important.
 
 Thanks,
 
 Felix
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3
 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4
 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf
 hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF
 JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm
 RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow
 BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1
 EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS
 eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB
 reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ
 mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii
 Mfj0LIA1IawOjtYjlnHz
 =lXSV
 -END PGP SIGNATURE-
 
 

Re: JavaFX features in JDK 9

[Felix Bembrick]

Well, we are all at the whim of Oracle executives decisions with the added help 
of third parties such as Gluon and RoboVM. The future of JavaFX really is in 
*our* hands.



 On 30 Jun 2015, at 21:13, Jack Moxley j...@moxley.co.uk wrote:
 
 Maybe it should its aspirations a little higher, especially with the advent 
 of unity, webgl or even scenegraph impls such as jmonkeyengine that do.
 
 Sent from my iPhone
 
 On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com wrote:
 
 coughJavaFX has *never* claimed to be write once, run anyway/cough
 
 
 On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote:
 
 coughwrite once, run anywhere/cough
 
 This about sums it up!
 
 
 
 On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk wrote:
 
 coughwrite once, run anywhere/cough
 
 Sent from my iPhone
 
 On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Does it mean platform support for linux won't be implemented now, or
 at all?
 I usually use windows, but still depend on that support because I
 sometimes use linux, so I am interested about that.
 
 W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze:
 There is public API in 8u40 to support accessibility. Applications
 using standard JavaFX controls can, for example, use the
 accessibleText property to define the text that the screen reader
 will speak or the accessibleHelp property to provide a more
 detailed description. These properties have reasonable defaults,
 but can be overridden by applications. Additionally, if you use the
 labelFor property to point to a Control that the Label is
 associated with, the accessibility framework will use that when the
 screen reader is active.
 
 Custom controls can override the queryAccessibleAttribute,
 executeAccessibleAction, and notifyAccessibleAttributeChanged
 methods.
 
 As for platform support, we currently support Windows and Mac
 platforms. We have no plan to make FX accessible on Linux .
 
 -- Kevin
 
 
 Michał Zegan wrote: I saw it, and it seems promising, but: first,
 there is probably, or I heard it wrong? no public api for making
 accessibility related stuff... Also, I believe there is no linux
 accessibility bridge as opposed to windows and mac. And I do not
 know if I am wrong, or when this is going to be implemented.
 
 W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze:
 
 JavaFX accessibility is already implemented and was delivered
 in JDK 8u40.
 
 -- Kevin
 
 
 Michał Zegan wrote: What about accessibility work? Work on it
 has been started, but not sure if it is still targetted for
 9.
 
 W dniu 2015-06-27 o 20:16, Mike pisze:
 
 
 a lot of FULL blown Webrtc support and building
 something in Javafx (like Scene Builder) that Proves
 Webrtc support would be awesome. Ditto to Webgl
 support.
 
 On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth
 kevin.rushfo...@oracle.com
 
 
 wrote:
 
 Hi Felix,
 
 Sorry for the delay. Most of us were still pretty
 focused on 8u60, but we are turning our attention to
 JDK 9 now.
 
 The focus for JDK 9 is Jigsaw. The currently planned
 big features (JEPs) for FX in JDK 9 are these:
 
 JEP 253: Prepare JavaFX UI Controls  CSS APIs for
 Modularization JEP 257: Update JavaFX/Media to Newer
 Version of GStreamer
 
 Related to Jigasw, we intend to look into new API for
 heavily used internal methods / classes since they
 will no longer be accessible otherwise. We also plan
 to update WebKit at least one more time, and will
 likely do a few RFEs such as better Hi-DPI support
 (with API control) on Mac, Windows, Linux.
 
 We don't currently plan any other big features for 9,
 but will consider additional RFEs if they are
 important to enough developers and if they fit into
 the time frame.
 
 -- Kevin
 
 
 
 Felix Bembrick wrote:
 
 
 
 Anyone got anything or is there a link somewhere
 that talks about these?
 
 On 15 June 2015 at 22:00, Felix Bembrick
 felix.bembr...@gmail.com wrote:
 
 
 
 
 
 I realise we are a long way off JDK 9 still and
 with crucial features such as Jigsaw still a
 little up in the air but is it possible someone
 could itemise the most likely new features,
 enhancements and bug fixes that we will see in
 JavaFX when JDK 9 is released?
 
 Of course it's purely speculation at this point
 but it would assist me greatly to have some of
 idea of where JavaFX is heading and which areas
 are seen as most important.
 
 Thanks,
 
 Felix
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3
 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4
 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf
 hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF
 JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm
 RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow
 BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1
 EZnfkXmXYi/lqgyRBf1

Re: JavaFX features in JDK 9

[Felix Bembrick]

Mike, I believe it is essential that the JavaFX WebView supports WebGL as
this is where a lot of the OpenGL work is being done now.  At the moment,
JavaFX WebView is limited to Lite Mode of Google Maps for example so it is
not really compatible with an external browser.  Other than that, there has
to be a seamless way of integrating custom shaders and arbitrary OpenGL in
a way that works in conjunction with the scene graph.  Current 3D support
in JavaFX is token at best...

On 30 June 2015 at 21:21, Jack Moxley j...@moxley.co.uk wrote:

 I suppose i should stop shouting from the sidelines, roll up my sleeves
 and get my hands dirty, what can i do as a lowly developer to help?

 Sent from my iPhone

  On 30 Jun 2015, at 12:16, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  Well, we are all at the whim of Oracle executives decisions with the
 added help of third parties such as Gluon and RoboVM. The future of JavaFX
 really is in *our* hands.
 
 
 
  On 30 Jun 2015, at 21:13, Jack Moxley j...@moxley.co.uk wrote:
 
  Maybe it should its aspirations a little higher, especially with the
 advent of unity, webgl or even scenegraph impls such as jmonkeyengine that
 do.
 
  Sent from my iPhone
 
  On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  coughJavaFX has *never* claimed to be write once, run anyway/cough
 
 
  On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote:
 
  coughwrite once, run anywhere/cough
 
  This about sums it up!
 
 
 
  On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk
 wrote:
 
  coughwrite once, run anywhere/cough
 
  Sent from my iPhone
 
  On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl
 
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Does it mean platform support for linux won't be implemented now, or
  at all?
  I usually use windows, but still depend on that support because I
  sometimes use linux, so I am interested about that.
 
  W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze:
  There is public API in 8u40 to support accessibility. Applications
  using standard JavaFX controls can, for example, use the
  accessibleText property to define the text that the screen reader
  will speak or the accessibleHelp property to provide a more
  detailed description. These properties have reasonable defaults,
  but can be overridden by applications. Additionally, if you use the
  labelFor property to point to a Control that the Label is
  associated with, the accessibility framework will use that when the
  screen reader is active.
 
  Custom controls can override the queryAccessibleAttribute,
  executeAccessibleAction, and notifyAccessibleAttributeChanged
  methods.
 
  As for platform support, we currently support Windows and Mac
  platforms. We have no plan to make FX accessible on Linux .
 
  -- Kevin
 
 
  Michał Zegan wrote: I saw it, and it seems promising, but: first,
  there is probably, or I heard it wrong? no public api for making
  accessibility related stuff... Also, I believe there is no linux
  accessibility bridge as opposed to windows and mac. And I do not
  know if I am wrong, or when this is going to be implemented.
 
  W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze:
 
  JavaFX accessibility is already implemented and was delivered
  in JDK 8u40.
 
  -- Kevin
 
 
  Michał Zegan wrote: What about accessibility work? Work on it
  has been started, but not sure if it is still targetted for
  9.
 
  W dniu 2015-06-27 o 20:16, Mike pisze:
 
 
  a lot of FULL blown Webrtc support and building
  something in Javafx (like Scene Builder) that Proves
  Webrtc support would be awesome. Ditto to Webgl
  support.
 
  On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth
  kevin.rushfo...@oracle.com
 
 
  wrote:
 
  Hi Felix,
 
  Sorry for the delay. Most of us were still pretty
  focused on 8u60, but we are turning our attention to
  JDK 9 now.
 
  The focus for JDK 9 is Jigsaw. The currently planned
  big features (JEPs) for FX in JDK 9 are these:
 
  JEP 253: Prepare JavaFX UI Controls  CSS APIs for
  Modularization JEP 257: Update JavaFX/Media to Newer
  Version of GStreamer
 
  Related to Jigasw, we intend to look into new API for
  heavily used internal methods / classes since they
  will no longer be accessible otherwise. We also plan
  to update WebKit at least one more time, and will
  likely do a few RFEs such as better Hi-DPI support
  (with API control) on Mac, Windows, Linux.
 
  We don't currently plan any other big features for 9,
  but will consider additional RFEs if they are
  important to enough developers and if they fit into
  the time frame.
 
  -- Kevin
 
 
 
  Felix Bembrick wrote:
 
 
 
  Anyone got anything or is there a link somewhere
  that talks about these?
 
  On 15 June 2015 at 22:00, Felix Bembrick
  felix.bembr...@gmail.com wrote:
 
 
 
 
 
  I realise we are a long way off JDK 9 still and
  with crucial features such as Jigsaw still a
  little up in the air

Re: JavaFX features in JDK 9

[Felix Bembrick]

I have to say that I agree with Mike that WebGL support is an absolute must 
especially when you consider how rudimentary the current JavaFX 3D features are.

 On 28 Jun 2015, at 04:16, Mike mikeg...@gmail.com wrote:
 
 a lot of FULL blown Webrtc support and building something in Javafx (like 
 Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl 
 support. 
 
 On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 Hi Felix,
 
 Sorry for the delay. Most of us were still pretty focused on 8u60, but we 
 are turning our attention to JDK 9 now.
 
 The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for 
 FX in JDK 9 are these:
 
 JEP 253: Prepare JavaFX UI Controls  CSS APIs for Modularization
 JEP 257: Update JavaFX/Media to Newer Version of GStreamer
 
 Related to Jigasw, we intend to look into new API for heavily used internal 
 methods / classes since they will no longer be accessible otherwise. We also 
 plan to update WebKit at least one more time, and will likely do a few RFEs 
 such as better Hi-DPI support (with API control) on Mac, Windows, Linux.
 
 We don't currently plan any other big features for 9, but will consider 
 additional RFEs if they are important to enough developers and if they fit 
 into the time frame.
 
 -- Kevin
 
 
 
 Felix Bembrick wrote:
 Anyone got anything or is there a link somewhere that talks about these?
 
 On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote:
 
   
 I realise we are a long way off JDK 9 still and with crucial features such
 as Jigsaw still a little up in the air but is it possible someone could
 itemise the most likely new features, enhancements and bug fixes that we
 will see in JavaFX when JDK 9 is released?
 
 Of course it's purely speculation at this point but it would assist me
 greatly to have some of idea of where JavaFX is heading and which areas are
 seen as most important.
 
 Thanks,
 
 Felix
 
 

Re: JavaFX features in JDK 9

[Felix Bembrick]

Thanks Kevin but I am left a little underwhelmed by this tiny list. It seems 
that JavaFX is perhaps the slowest evolving technology in history in many 
respects which is very disappointing.


 On 28 Jun 2015, at 01:07, Kevin Rushforth kevin.rushfo...@oracle.com wrote:
 
 Hi Felix,
 
 Sorry for the delay. Most of us were still pretty focused on 8u60, but we are 
 turning our attention to JDK 9 now.
 
 The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for 
 FX in JDK 9 are these:
 
 JEP 253: Prepare JavaFX UI Controls  CSS APIs for Modularization
 JEP 257: Update JavaFX/Media to Newer Version of GStreamer
 
 Related to Jigasw, we intend to look into new API for heavily used internal 
 methods / classes since they will no longer be accessible otherwise. We also 
 plan to update WebKit at least one more time, and will likely do a few RFEs 
 such as better Hi-DPI support (with API control) on Mac, Windows, Linux.
 
 We don't currently plan any other big features for 9, but will consider 
 additional RFEs if they are important to enough developers and if they fit 
 into the time frame.
 
 -- Kevin
 
 
 Felix Bembrick wrote:
 Anyone got anything or is there a link somewhere that talks about these?
 
 On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote:
 
  
 I realise we are a long way off JDK 9 still and with crucial features such
 as Jigsaw still a little up in the air but is it possible someone could
 itemise the most likely new features, enhancements and bug fixes that we
 will see in JavaFX when JDK 9 is released?
 
 Of course it's purely speculation at this point but it would assist me
 greatly to have some of idea of where JavaFX is heading and which areas are
 seen as most important.
 
 Thanks,
 
 Felix

Re: JavaFX features in JDK 9

[Felix Bembrick]

Why are you asking me?

On 28 June 2015 at 05:24, Mike mikeg...@gmail.com wrote:

 Felix how many full time Engineers does Oracle have on Javafx and Java?
 How does this break up? How many open source contributors are Committing
 often?

 On Sat, Jun 27, 2015 at 11:38 AM, Felix Bembrick felix.bembr...@gmail.com
  wrote:

 Thanks Kevin but I am left a little underwhelmed by this tiny list. It
 seems that JavaFX is perhaps the slowest evolving technology in history in
 many respects which is very disappointing.


  On 28 Jun 2015, at 01:07, Kevin Rushforth kevin.rushfo...@oracle.com
 wrote:
 
  Hi Felix,
 
  Sorry for the delay. Most of us were still pretty focused on 8u60, but
 we are turning our attention to JDK 9 now.
 
  The focus for JDK 9 is Jigsaw. The currently planned big features
 (JEPs) for FX in JDK 9 are these:
 
  JEP 253: Prepare JavaFX UI Controls  CSS APIs for Modularization
  JEP 257: Update JavaFX/Media to Newer Version of GStreamer
 
  Related to Jigasw, we intend to look into new API for heavily used
 internal methods / classes since they will no longer be accessible
 otherwise. We also plan to update WebKit at least one more time, and will
 likely do a few RFEs such as better Hi-DPI support (with API control) on
 Mac, Windows, Linux.
 
  We don't currently plan any other big features for 9, but will consider
 additional RFEs if they are important to enough developers and if they fit
 into the time frame.
 
  -- Kevin
 
 
  Felix Bembrick wrote:
  Anyone got anything or is there a link somewhere that talks about
 these?
 
  On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
 
  I realise we are a long way off JDK 9 still and with crucial features
 such
  as Jigsaw still a little up in the air but is it possible someone
 could
  itemise the most likely new features, enhancements and bug fixes that
 we
  will see in JavaFX when JDK 9 is released?
 
  Of course it's purely speculation at this point but it would assist me
  greatly to have some of idea of where JavaFX is heading and which
 areas are
  seen as most important.
 
  Thanks,
 
  Felix
 

Re: JavaFX features in JDK 9

[Felix Bembrick]

Anyone got anything or is there a link somewhere that talks about these?

On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote:

 I realise we are a long way off JDK 9 still and with crucial features such
 as Jigsaw still a little up in the air but is it possible someone could
 itemise the most likely new features, enhancements and bug fixes that we
 will see in JavaFX when JDK 9 is released?

 Of course it's purely speculation at this point but it would assist me
 greatly to have some of idea of where JavaFX is heading and which areas are
 seen as most important.

 Thanks,

 Felix

JavaFX features in JDK 9

[Felix Bembrick]

I realise we are a long way off JDK 9 still and with crucial features such as 
Jigsaw still a little up in the air but is it possible someone could itemise 
the most likely new features, enhancements and bug fixes that we will see in 
JavaFX when JDK 9 is released?

Of course it's purely speculation at this point but it would assist me greatly 
to have some of idea of where JavaFX is heading and which areas are seen as 
most important.

Thanks,

Felix

Re: Font rendering hints - RT-36146 - progress?

[Felix Bembrick]

The thing is that the way DirectWrite is utilised now by JavaFX either
through which hints are applied by default or by some other way, the result
is text which does not render exactly the same way as (almost) every native
Windows application that also utilises DirectWrite.

Wouldn't a simpler solution (or at least a first step) be just to tweak the
hints and options until JavaFX font rendering on Windows matches the way
native apps do it?  I believe at the moment all the default options are
selected so perhaps experimenting with some of the non-default options or
examining actual code of some native apps to see which options/hints they
are setting would arrive at a best match configuration that could replace
the all defaults configuration we have now?

Then, later down the track, these hints/options could potentially be made
user-configurable.

On 16 June 2015 at 06:05, Phil Race philip.r...@oracle.com wrote:

 I would have to look at it starting more or less from scratch
 and I do not know that it would be as simple as providing a
 way to tweak DirectWrite rendering. The
 differences seem to be quite small differences in sub-pixel
 intensity and sub-pixel accumulation of the total advance.
 I do not know what API or client produced the 'native' rendering.
 And what if someone else wants something different again ?
 So I am not sure when we will get to looking into this and
 deciding if it makes sense.

 -phil.


 On 06/14/2015 02:31 PM, Felix Bembrick wrote:

 ​Has anyone had a look at this, done some work on it or can provide some
 details as to its progress?

 Thanks,

 Felix​

 On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com
 wrote:

  I am following this one closely and hoping that some progress has been
 made and that a fix is planned but it's difficult to determine from the
 JIRA issue.

 Does anyone have any additional info on where this issue is at?

 Thanks,

 Felix

Re: Font rendering hints - RT-36146 - progress?

[Felix Bembrick]

​Has anyone had a look at this, done some work on it or can provide some
details as to its progress?

Thanks,

Felix​

On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com wrote:

 I am following this one closely and hoping that some progress has been
 made and that a fix is planned but it's difficult to determine from the
 JIRA issue.

 Does anyone have any additional info on where this issue is at?

 Thanks,

 Felix

Font rendering hints - RT-36146 - progress?

[Felix Bembrick]

I am following this one closely and hoping that some progress has been made
and that a fix is planned but it's difficult to determine from the JIRA
issue.

Does anyone have any additional info on where this issue is at?

Thanks,

Felix

Re: Enhancements to 3D for JFX9?

[Felix Bembrick]

Anyone?

Felix

 On 22 Apr 2015, at 14:35, Felix Bembrick felix.bembr...@gmail.com wrote:
 
 What about:
 
 1) Custom shaders
 2) 3D Canvas
 
 Felix
 
 On 22 April 2015 at 11:37, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 Of these, handling transparency / blending is likely for JDK 9.
 
 -- Kevin
 
 
 
 Herve Girod wrote:
 Hello,
 
 As a newbie user of Java 3D, I have some suggestions in the back of my head
 for Java 9, as for example:
 - managing opacity (alpha) on 3D Node (the most important IMO)
 - parallel lights
 - managing far / near clip with parallel camera
 - some more built-in 3D Shapes would be useful
 
 I think that most, if not all, of these are already filed in JIRA.
 
 Hervé
 
 2015-04-20 13:15 GMT+02:00 Felix Bembrick felix.bembr...@gmail.com:
 
   
 As awesome as JavaFX is right now, for me it's greatest weakness
 especially when compared to competing products is it's extremely
 rudimentary support for 3D graphics. Even the old Java3D was considerably
 more advanced.
 
 Is beefing up 3D support in JFX9 seen as a priority and if so what
 features are being considered?
 
 I am not expecting a full-on rival for Unity3D but I am hoping to be able
 to build complex 3D games and scientific visualisations using custom
 shaders etc. and support for WebGL not just within WebKit itself but in a
 stand alone 3D Canvas node with full and extra 3D features.
 
 Of course all of this must work not just on the desktop but also on mobile
 platforms and embedded where feasible.
 
 Am I dreaming?
 
 Felix
 

Enhancements to 3D for JFX9?

[Felix Bembrick]

As awesome as JavaFX is right now, for me it's greatest weakness especially 
when compared to competing products is it's extremely rudimentary support for 
3D graphics. Even the old Java3D was considerably more advanced.

Is beefing up 3D support in JFX9 seen as a priority and if so what features are 
being considered?

I am not expecting a full-on rival for Unity3D but I am hoping to be able to 
build complex 3D games and scientific visualisations using custom shaders etc. 
and support for WebGL not just within WebKit itself but in a stand alone 3D 
Canvas node with full and extra 3D features.

Of course all of this must work not just on the desktop but also on mobile 
platforms and embedded where feasible. 

Am I dreaming?

Felix

Re: libjfxmedia.so on armv6hf?

[Felix Bembrick]

Yes Fabrizio, I agree with you.  First it was iOS, then Android and now
ARM. Oracle the company seem to view JavafX or their support for it as just
a fancy Swing replacement to run exclusively on desktop operating systems
like Windows, MacOS and Linux.  But can we even trust that they will
continue to invest in those platforms?  The problem seems to be as simple
that Oracle makes little or no money directly from JavaFX and being a very
profit focused company, why would they care about it?

Their attitude now is that is you want JavaFX to actually work on anything
other than the desktop (i.e. on all the modern devices that most people are
actually using these days) then the community must step-up and make it
happen.  Thats a very disappointing and concerning attitude to say the
least!

Fortunately some in the community, notably Johan Vos and his company Gluon
and Niklas Therning with RoboVM have stepped-up to try to fill this void
but we are talking about a handful of people with shoestring budgets trying
to get sophisticated technology working on an enormous range of complex and
highly fragmented modern devices.  How can they compete with a company like
Qt which exists *only* to develop and sell Qt and have at least one hundred
developers working on each of the iOS and Android ports and already have
viable mobile apps using Qt selling out there in the marketplace.

I really admire guys like this and wish that my own personal circumstances
enabled me to get involved in a similar way but my main concern is that the
community required to make JavaFX truly viable on iOS, Android and ARM
needs to be about 50-100 times bigger than it currently is.  Without an
overall corporation paying the wages of these people, how is that ever
going to happen?  And by truly viable I mean making JavaFX a technology
that can be used for *serious commercial application development *on all
those platforms.  Pretty gauges and simple square-based games are not
enough to sustain or interest software houses to adopt JavaFX to develop
their products and until that happens, JavaFX is going to struggle...

Felix

On 17 March 2015 at 10:53, Fabrizio Giudici fabrizio.giud...@tidalwave.it
wrote:

 On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth 
 kevin.rushfo...@oracle.com wrote:

  Unlikely without help from the community, given that FX itself is no
 longer supported on linux-arm. We currently have no plan to add such
 support.


 Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/
 forums/viewtopic.php?f=81t=97367

 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning
 about writing a media center prototype with some ideas in mind. In the past
 years I did lots of stuff with imaging and media, and was with Swing. I
 struggled with tons of incomplete features in the imaging and movie APIs,
 lots of additional libraries in order to have a decent modern UI (with
 animations and such), because Java didn't offer them out of the box. In the
 end I quit because it was frustrating to always be forced to fix something
 at the basics level. I mean, I just wanted to focus on the application.
 Now, fast forward some years and we have that Java FX, with bells and
 whistles. I supposed I could at last enjoy writing an app on the RPI
 without worrying about missing, incomplete, partially unsupported stuff,
 but I was wrong. It seems that no matter Sun or Oracle, there's a sort of
 curse preventing the Java ecosystem to fully work on the reference rich UI
 hardware.

 Sorry for the rant, nothing against people of course, but that's just my
 feelings at the moment.

 --
 Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
 We make Java work. Everywhere.
 http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: libjfxmedia.so on armv6hf?

[Felix Bembrick]

Will they ever be supported?

On 17 March 2015 at 10:14, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:

 Media and web have not ever been supported or delivered on linux-arm.

 Seems that libjfxmedia.so should be excluded by the openZips target. David
 can response further.

 -- Kevin



 Chris Newland wrote:

 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=
 97367p=720267#p720267

 When cross-compiling to armv6hf on an x86-64 Linux system using:

 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:

 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
 object,
 x86-64, version 1 (SYSV), dynamically linked,
 BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped

 Is this a simple gradle error or is it not currently possible to build
 some of the JavaFX libraries for ARM?

 Thanks,

 Chris

Re: JavaFX embedded (graphics example / performance test)

[Felix Bembrick]

Hi Prasant,

I have been working on just such a beast for much longer than I had
intended (family commitments, illness, wedding to organise, you know) which
I call *FXMark*.

I had originally intended to release *FXMark* earlier this year but in
reality it won't be out there until after my wedding in January.  However,
it will be a much more sophisticated animal and will really highlight what
can be done with animations of nodes in the scenegraph along with
permitting observation of the effects of applying various effects and
caching strategies.

I am sorry I cannot give you an official release date but expect it
sometime in the New Year.

You can read a little but about it and see more about me at my blog
http://justmy2bits.com

Cheers,

Felix


On 11 December 2014 at 00:05, Prasant J pj0...@gmail.com wrote:

 Hi,

 Is there any JavaFX test program that can be used for
 testing/comparing graphics performance?


 Regards, Pj

Re: What Scene Builder needs YESTERDAY!

[Felix Bembrick]

I am surprised more people have not expressed an opinion on this.  To me,
it seems absolutely *vital* to the long term (or any term) success of
JavaFX.

Haven't any of you ever programmed in Flash?  Can you imagine trying to
create any of those complex (or even the simple) animations and
visualisations *without* a visual editor and by doing it code alone?  It
wouldn't have been practical (read possible) and similarly, and with JavaFX
having even richer features, to do this by hand.

To me, this is the reason why we haven't seen any great
animations/visualisations/applications using JavaFX and we probably never
will until a visual animation editor is available.  Specifying and
controlling the motion and appearance of numerous complex objects and their
transitions relying exclusively on code would not be possible for even the
gunnest JFX coder...

On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com wrote:

 I’m afraid at this time there are no plans for adding an
 animation/transition effect editor to Scene Builder, certainly not in the
 short-term.

 Thanks
 Richard

  On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  Java applets were the first programs to run inside a web browser and
 for
  a (little) while they were flavour of the month.
 
  But then along came Flash which had several advantages such as faster
 load
  times, consistent loads and antialiased fonts/graphics and soon
 completely
  surpassed applets.
 
  But the MAIN reason why Flash was initially so successful and went on for
  years and years of domination is that the Flash tools had an
  Animation/Timeline Editor pretty much from the beginning.  This enabled
  even a novice to drag images around and draw the path they wanted them to
  move along, add all sorts of bouncing effects and sounds and the result
 was
  the birth of the online greeting card company.
 
  But Flash soon went on to be so much more.  As the Adobe tools improved,
 so
  did the SWFs and soon entire websites were written in Flash.
 
  Meanwhile, applet programmers had absolutely nothing remotely similar and
  had to try (and I stress try) to tediously hand code any animations and
  transitions and effects and I don't think it ever worked.
 
  Fast forward 15-20 years and now we have JavaFX which doesn't need to run
  in the browser, has even more features than Flash, uses hardware
  acceleration for superior performance, has a wide range of built-in
  animations, transitions and effects but STILL we have to hand code any
  animation/transitions.
 
  This is INCREDIBLY inefficient and unless Scene Builder incorporates a
  powerful, sophisticated animation/transition and effect editor VERY, VERY
  SOON I fear that the advanced graphics features are never going to be
 used
  to their full potential (much to the detriment of JavaFX itself).
 
  Does anyone know if one is in the pipeline?  I see this as one of the
 most
  vital features for the JavaFX ecosystem to achieve more penetration and,
  eventually, survive.
 
  Felix

Re: What Scene Builder needs YESTERDAY!

[Felix Bembrick]

Really?  My point is, why have such good built-on classes to support the
building of everything from simple animations to complex visualisations if
it is practically impossible to do so?

On 24 November 2014 at 21:02, Tom Eugelink t...@tbee.org wrote:

 I do not think that JavaFX is aiming at replacing flash, HTML and
 javascript are doing a great job there, hence animations are not equally
 important as they were for flash.

 Tom



 On 24-11-2014 10:46, Felix Bembrick wrote:

 I am surprised more people have not expressed an opinion on this.  To me,
 it seems absolutely *vital* to the long term (or any term) success of
 JavaFX.

 Haven't any of you ever programmed in Flash?  Can you imagine trying to
 create any of those complex (or even the simple) animations and
 visualisations *without* a visual editor and by doing it code alone?  It
 wouldn't have been practical (read possible) and similarly, and with
 JavaFX
 having even richer features, to do this by hand.

 To me, this is the reason why we haven't seen any great
 animations/visualisations/applications using JavaFX and we probably never
 will until a visual animation editor is available.  Specifying and
 controlling the motion and appearance of numerous complex objects and
 their
 transitions relying exclusively on code would not be possible for even the
 gunnest JFX coder...

 On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com
 wrote:

  I’m afraid at this time there are no plans for adding an
 animation/transition effect editor to Scene Builder, certainly not in the
 short-term.

 Thanks
 Richard

  On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com

 wrote:

 Java applets were the first programs to run inside a web browser and

 for

 a (little) while they were flavour of the month.

 But then along came Flash which had several advantages such as faster

 load

 times, consistent loads and antialiased fonts/graphics and soon

 completely

 surpassed applets.

 But the MAIN reason why Flash was initially so successful and went on
 for
 years and years of domination is that the Flash tools had an
 Animation/Timeline Editor pretty much from the beginning.  This enabled
 even a novice to drag images around and draw the path they wanted them
 to
 move along, add all sorts of bouncing effects and sounds and the result

 was

 the birth of the online greeting card company.

 But Flash soon went on to be so much more.  As the Adobe tools improved,

 so

 did the SWFs and soon entire websites were written in Flash.

 Meanwhile, applet programmers had absolutely nothing remotely similar
 and
 had to try (and I stress try) to tediously hand code any animations and
 transitions and effects and I don't think it ever worked.

 Fast forward 15-20 years and now we have JavaFX which doesn't need to
 run
 in the browser, has even more features than Flash, uses hardware
 acceleration for superior performance, has a wide range of built-in
 animations, transitions and effects but STILL we have to hand code any
 animation/transitions.

 This is INCREDIBLY inefficient and unless Scene Builder incorporates a
 powerful, sophisticated animation/transition and effect editor VERY,
 VERY
 SOON I fear that the advanced graphics features are never going to be

 used

 to their full potential (much to the detriment of JavaFX itself).

 Does anyone know if one is in the pipeline?  I see this as one of the

 most

 vital features for the JavaFX ecosystem to achieve more penetration and,
 eventually, survive.

 Felix

Re: What Scene Builder needs YESTERDAY!

[Felix Bembrick]

JavaFX should not be seen as a replacement for anything or an
alternative.  It has characteristics of both Flash and Flex along with
Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a
separate and distinct product in its own class.

Just because the Flash visual editor may have got in the way of your
desire to code directly, that doesn't mean that JavaFX should not have such
an editor for all the same reasons and use cases that Flash had one.

Sure, for *your* purposes of decorative effects, I am confident that
coding would suffice but for *my* purposes (and anyone who has worked in
the animation industry or worked creating visualisations) I really need a
visual editor of the ilk I have described.

Why just make one class of user happy but seriously limit the effectiveness
of another (and in doing so possibly significantly limit the market of
JavaFX)?

I am sure at least one of the developers on the JavaFX team has at one
point at least envisaged JavaFX being used for complex animations,
visualisations or even non-trivial games.  What they need to do now is make
such use cases feasible.

On 24 November 2014 at 22:04, Tom Eugelink t...@tbee.org wrote:

  I have no problems using JavaFX's animations for my purposes, which are
 decorative effects. I do not need an editor for that, forced me to use it
 and it probably will even get in my way. Which BTW was the case with the
 Flash coding that I have done; I hated that Flash EDI, it was way too much
 focussed on animation. Actually that is why Adobe created Flex, which
 basically was flash-for-developers (instead of animators). JavaFX is more a
 alternative for Flex than Flash.

 Tom



 On 24-11-2014 11:20, Felix Bembrick wrote:

  Really?  My point is, why have such good built-on classes to support the
 building of everything from simple animations to complex visualisations if
 it is practically impossible to do so?

 On 24 November 2014 at 21:02, Tom Eugelink t...@tbee.org wrote:

 I do not think that JavaFX is aiming at replacing flash, HTML and
 javascript are doing a great job there, hence animations are not equally
 important as they were for flash.

 Tom



 On 24-11-2014 10:46, Felix Bembrick wrote:

 I am surprised more people have not expressed an opinion on this.  To me,
 it seems absolutely *vital* to the long term (or any term) success of
 JavaFX.

 Haven't any of you ever programmed in Flash?  Can you imagine trying to
 create any of those complex (or even the simple) animations and
 visualisations *without* a visual editor and by doing it code alone?  It
 wouldn't have been practical (read possible) and similarly, and with
 JavaFX
 having even richer features, to do this by hand.

 To me, this is the reason why we haven't seen any great
 animations/visualisations/applications using JavaFX and we probably never
 will until a visual animation editor is available.  Specifying and
 controlling the motion and appearance of numerous complex objects and
 their
 transitions relying exclusively on code would not be possible for even
 the
 gunnest JFX coder...

 On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com
 wrote:

  I’m afraid at this time there are no plans for adding an
 animation/transition effect editor to Scene Builder, certainly not in
 the
 short-term.

 Thanks
 Richard

  On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com

 wrote:

 Java applets were the first programs to run inside a web browser and

 for

 a (little) while they were flavour of the month.

 But then along came Flash which had several advantages such as faster

 load

 times, consistent loads and antialiased fonts/graphics and soon

 completely

 surpassed applets.

 But the MAIN reason why Flash was initially so successful and went on
 for
 years and years of domination is that the Flash tools had an
 Animation/Timeline Editor pretty much from the beginning.  This enabled
 even a novice to drag images around and draw the path they wanted them
 to
 move along, add all sorts of bouncing effects and sounds and the result

 was

 the birth of the online greeting card company.

 But Flash soon went on to be so much more.  As the Adobe tools
 improved,

 so

 did the SWFs and soon entire websites were written in Flash.

 Meanwhile, applet programmers had absolutely nothing remotely similar
 and
 had to try (and I stress try) to tediously hand code any animations and
 transitions and effects and I don't think it ever worked.

 Fast forward 15-20 years and now we have JavaFX which doesn't need to
 run
 in the browser, has even more features than Flash, uses hardware
 acceleration for superior performance, has a wide range of built-in
 animations, transitions and effects but STILL we have to hand code any
 animation/transitions.

 This is INCREDIBLY inefficient and unless Scene Builder incorporates a
 powerful, sophisticated animation/transition and effect editor VERY,
 VERY
 SOON I fear that the advanced graphics features

Re: What Scene Builder needs YESTERDAY!

[Felix Bembrick]

On 25 November 2014 at 17:24, Tom Eugelink t...@tbee.org wrote:

 the question is, should it be working good in one area or only half in two?


​That's an age-old problem I guess Tom.  Personally I feel that traditional
forms/dialogs based applications have enough support in Scene Builder as it
is with version 2.0 (and I am sure another release can't be far away) to be
able to be done effectively so perhaps more advanced use cases can be given
a bit of love now?​