Re: Planning for JavaFX.next

[Matthew Elliot]

+1 for CSS perf (diagnostic tooling for slow selectors like @Daniel Gloeckner 
referenced earlier would also be a bonus)
+ for scene graph rendering perf
+ table perf
+ table features and fixes (column freezing, row span, selection model fixes 
and memory leak fixes)
+ integration of controlsfx into JFX.

Matt. 

Sent from my phone.

> On 8/12/2016, at 7:07 AM, Chris Newland  wrote:
> 
> Hi Jonathan,
> 
> +1 to that list for me.
> 
> In my experience JavaFX performs well for the "low-level" (Canvas +
> GraphicsContext) stuff with one exception - the PixelWriter APIs appear do
> a lot of array duplication and copying under the hood which I believe can
> be optimised. I'll investigate further and try to come up with a patch.
> 
> Nice to have (but lower priority than everything on the list) would be a
> public API for grabbing frames from a MediaPlayer which used to be
> possible in 8 with player.impl_getLatestFrame().
> 
> Echoing Tom and Felix, my #1 priority would be fixing scenegraph
> performance as tables with large row counts and charts (e.g. XYChart) with
> large numbers of data points (e.g. 50K) in their Series can easily lead to
> multi-second render times and huge heap usage.
> 
> Thanks for opening this discussion,
> 
> Chris
> 
>> On Wed, December 7, 2016 23: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: Planning for JavaFX.next

[Michael Ennen]

Keeping WebKit as up-to-date with upstream as possible is the most
important thing for me personally.

Also upgrading the "org.w3c.dom" from HTML 4 to HTML 5 is a big one as
well. As an example,
the version of WebKit JavaFX uses supports "Document.querySelectorAll()"
which can be used via:

webView = new WebView();
HTMLDivElement divElement = (HTMLDivElement)
webView.getEngine().executeScript(
"document.querySelectorAll('div.note, div.alert')[0]");

However this is not type-safe. If the "org.w3c.dom" library was updated for
HTML 5
then the type-safe:

HTMLDivElement divElement
webView.getEngine().getDocument().querySelectorAll(
"div.note, div.alert")[0]; // or get(0), depending on if Collection
or array is returned

version could be used instead.

This is just a silly made-up example, but it illustrates the point (I
hope!) that not having
the "org.w3c.dom" library as up-to-date as the WebKit version makes
programatically
executing Javascript code on a WebView less than ideal (mostly for reasons
of type safety,
as I mentioned.)

As for the list in the OP, I would give +1's to:

New layout containers (e.g. Flexbox)
Support for CSS animations
TableView improvements (cell spanning, row / column freezing, etc)
TableView performance
A JavaFX equivalent of the AWT Desktop APIs

Thanks,
Michael

On Wed, Dec 7, 2016 at 4:45 PM, 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

[Chris Newland]

Hi Jonathan,

+1 to that list for me.

In my experience JavaFX performs well for the "low-level" (Canvas +
GraphicsContext) stuff with one exception - the PixelWriter APIs appear do
a lot of array duplication and copying under the hood which I believe can
be optimised. I'll investigate further and try to come up with a patch.

Nice to have (but lower priority than everything on the list) would be a
public API for grabbing frames from a MediaPlayer which used to be
possible in 8 with player.impl_getLatestFrame().

Echoing Tom and Felix, my #1 priority would be fixing scenegraph
performance as tables with large row counts and charts (e.g. XYChart) with
large numbers of data points (e.g. 50K) in their Series can easily lead to
multi-second render times and huge heap usage.

Thanks for opening this discussion,

Chris

On Wed, December 7, 2016 23: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: Planning for JavaFX.next

[Tom Schindl]

Hi,

I agree the JavaFX team should focus on the core:

* CSS & SG Performance - Like Felix says this needs to be improved
  significantly. It is unjustifable that JavaFX is lagging so much
  behind Browsers and other UI-Toolkits

* WebGL support in WebView or a way to run Chromium as an external
  process and pipeing back the output - I would not mind of this webiew
  is not taking part in all SG-Transformations like Scaling, ...

Layout-Containers, Installers, ... can be done outside of JavaFX

Tom

On 08.12.16 06:19, Tom Eugelink wrote:
> From my perspective, from this list, TableView is a big candidate to get
> some real TLC. And about animations; for testing it is very important to
> be able to _easy_ detect when an animation is still active (one of the
> biggest problems I currently have with CSS 3 animations).
> 
> About Layout containers, those are fairly easily written by the
> community, so I'm not sure is that is what you should be focusing at.
> I've done MigPane and am now working on ResponsivePane. I think the
> JavaFX team should more focus on the core?
> 
> And do add mobile to that core please. Maybe not the full monty like
> Gluon, but help as much as possible.
> 
> 
> 
> On 8-12-2016 00: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
> 
> 


-- 
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: Planning for JavaFX.next

[Jonathan Giles]

Tom,

Can you dive into what you want to see in TableView? Performance 
improvements, or some particular features?


Btw, I'd love to see someone in the community implement a flexbox 
layout. It seems to be what I hear most about these days.


Finally - have you tested your custom layouts on JDK 9 EA builds? I 
would suspect they don't work quite so well (i.e. I'd be surprised if 
you can still compile)so any feedback there about what is missing to 
you would also be very useful.


-- Jonathan

On 7/12/16 9:19 PM, Tom Eugelink wrote:
From my perspective, from this list, TableView is a big candidate to 
get some real TLC. And about animations; for testing it is very 
important to be able to _easy_ detect when an animation is still 
active (one of the biggest problems I currently have with CSS 3 
animations).


About Layout containers, those are fairly easily written by the 
community, so I'm not sure is that is what you should be focusing at. 
I've done MigPane and am now working on ResponsivePane. I think the 
JavaFX team should more focus on the core?


And do add mobile to that core please. Maybe not the full monty like 
Gluon, but help as much as possible.




On 8-12-2016 00: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: Planning for JavaFX.next

[Tom Eugelink]

From my perspective, from this list, TableView is a big candidate to get some 
real TLC. And about animations; for testing it is very important to be able to 
_easy_ detect when an animation is still active (one of the biggest problems I 
currently have with CSS 3 animations).

About Layout containers, those are fairly easily written by the community, so 
I'm not sure is that is what you should be focusing at. I've done MigPane and 
am now working on ResponsivePane. I think the JavaFX team should more focus on 
the core?

And do add mobile to that core please. Maybe not the full monty like Gluon, but 
help as much as possible.



On 8-12-2016 00: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: 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

Planning for JavaFX.next

[Jonathan Giles]

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

[9] Review request: JDK-8170879 Fix Quad / Cubic BND constants for Marlin (FX)

[Laurent Bourgès]

Please review this simple fix for MarlinFX:

JBS: https://bugs.openjdk.java.net/browse/JDK-8170879
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170879.0/

As mentioned in JBS, I studied both quality & performance and MarlinFX is
now slightly better than openpisces (1.6 vs 2.1 avg px).

I added attachements in JBS providing updated test classes (bug fix)


"
This simple fix changes MarlinFX renderers:
- use QUAD_DEC_BND=0.5 pixel
- cleaned up comments about both CUBIC / QUAD BND that are really related
to 2nd derivative (so expressed subpixels)
- modified the subdivision condition to use the manhattan norm |ddx| +
|ddy| instead of max( |ddx| , |ddy| ) to improve the average bad pixels
from 2.1 to 1.6 (30% better)

Quality tests after the fix:
cubic: bad paths (59294/10 == 59,29%, 94335 bad pixels (avg = 1,59),
3966 warnings (avg = 0,07)
quad: bad paths (62916/10 == 62,92%, 103818 bad pixels (avg = 1,65),
6514 warnings (avg = 0,10)


I also fixed the RasterPerf test that did not really tested the nonAA
performance as the antialiasing argument was hard-coded to true.

Here are the latest results still showing that MarlinFX is still the
fastest rasterizer (the fix caused only 3% slowdown on quads)

1656771 10x10 Rectangle native non-AA rasterizations took 2838.21ms,
583737.989789339 ops/sec
167656 100x100 Rectangle native non-AA rasterizations took 2988.26ms,
56104.89047137799 ops/sec
24657 300x300 Rectangle native non-AA rasterizations took 2999.07ms,
8221.548680090827 ops/sec
1095638 10x10 Ellipse native non-AA rasterizations took 2921.11ms,
375075.91292351193 ops/sec
141453 100x100 Ellipse native non-AA rasterizations took 2993.52ms,
47253.06662390764 ops/sec
23322 300x300 Ellipse native non-AA rasterizations took 2990.53ms,
7798.6176363387085 ops/sec
104167 100x100 Cubics native non-AA rasterizations took 2993.09ms,
34802.49508033504 ops/sec
179098 100x100 Quads native non-AA rasterizations took 2990.27ms,
59893.588204409636 ops/sec

697353 10x10 Rectangle native AA rasterizations took 2970.08ms,
234792.66551742714 ops/sec
69040 100x100 Rectangle native AA rasterizations took 2996.82ms,
23037.75335188633 ops/sec
15150 300x300 Rectangle native AA rasterizations took 3000.23ms,
5049.6128630138355 ops/sec
427194 10x10 Ellipse native AA rasterizations took 2984.12ms,
143155.77121563477 ops/sec
52642 100x100 Ellipse native AA rasterizations took 3000.88ms,
17542.187624963342 ops/sec
14141 300x300 Ellipse native AA rasterizations took 2999.32ms,
4714.735340010402 ops/sec
32264 100x100 Cubics native AA rasterizations took 3004.43ms,
10738.80902533925 ops/sec
65598 100x100 Quads native AA rasterizations took 2996.14ms,
21894.170499375865 ops/sec


2270203 10x10 Rectangle Java non-AA rasterizations took 2643.8ms,
858689.3864891444 ops/sec
130620 100x100 Rectangle Java non-AA rasterizations took 2933.28ms,
44530.355097365406 ops/sec
18158 300x300 Rectangle Java non-AA rasterizations took 2999.77ms,
6053.130740023402 ops/sec
1302146 10x10 Ellipse Java non-AA rasterizations took 2832.42ms,
459729.1362156742 ops/sec
115743 100x100 Ellipse Java non-AA rasterizations took 2980.09ms,
38838.759903224396 ops/sec
17448 300x300 Ellipse Java non-AA rasterizations took 3000.02ms,
5815.961226925154 ops/sec
90130 100x100 Cubics Java non-AA rasterizations took 2947.1ms,
30582.606630246682 ops/sec
153626 100x100 Quads Java non-AA rasterizations took 2981.04ms,
51534.36384617449 ops/sec


577864 10x10 Rectangle Java AA rasterizations took 2886.25ms,
200212.7327847553 ops/sec
49513 100x100 Rectangle Java AA rasterizations took 2997.83ms,
16516.280109279047 ops/sec
10649 300x300 Rectangle Java AA rasterizations took 2999.48ms,
3550.28204474 ops/sec
396414 10x10 Ellipse Java AA rasterizations took 2984.77ms,
132812.2434894481 ops/sec
40773 100x100 Ellipse Java AA rasterizations took 2999.61ms,
13592.767059717762 ops/sec
10132 300x300 Ellipse Java AA rasterizations took 2999.64ms,
3377.7386619727704 ops/sec
28466 100x100 Cubics Java AA rasterizations took 3080.16ms,
9241.727702457016 ops/sec
48989 100x100 Quads Java AA rasterizations took 2900.38ms,
16890.545376812694 ops/sec

2837061 10x10 Rectangle Marlin non-AA rasterizations took 2773.42ms,
1022946.7588753236 ops/sec
217841 100x100 Rectangle Marlin non-AA rasterizations took 2560.12ms,
85090.15202412388 ops/sec
48999 300x300 Rectangle Marlin non-AA rasterizations took 2966.98ms,
16514.772597051546 ops/sec
1165498 10x10 Ellipse Marlin non-AA rasterizations took 2259.69ms,
515777.82793215 ops/sec
145263 100x100 Ellipse Marlin non-AA rasterizations took 2450.31ms,
59283.51922817929 ops/sec
31591 300x300 Ellipse Marlin non-AA rasterizations took 2868.11ms,
11014.57057086374 ops/sec
93796 100x100 Cubics Marlin non-AA rasterizations took 2760.0ms,
33984.057971014496 ops/sec
182128 100x100 Quads Marlin non-AA rasterizations took 2978.02ms,
61157.413314887075 ops/sec

803422 10x10 Rectangle Marlin AA rasterizations took 2411.52ms,
333159.9986730361 ops/sec

Re: [9,8u] Review request: JDK-8088857 Menu slow to respond after resizing a window multiple times with animation running

[Jim Graham]

The fix applied cleanly to 8u-dev and fixed the same pair of bugs so this is 
now also a backport request.

8u-specific webrev: 
http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.8u.rt.00/

...jim

On 12/7/16 8:06 AM, Jim Graham wrote:

JBS: https://bugs.openjdk.java.net/browse/JDK-8088857
webrev: http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.rt.00/

Fix is as we discussed.

I'll investigate applying it to 8u-dev soon...

...jim

RFE/Suggestions to improve JavaFX deployment of javax.script (part of Java) engines and script code

[Rony G. Flatscher]

For scripting languages that possess javax.script (part of Java since Java 
1.6/6!) implementations
the JavaFX infrastructure is of a great attractivity.

JavaFX would allow script programmers for creating platform independent GUIs to 
take fully advantage
for their own purposes, i.e. "surfing on Java" to get at a modern, maintained, 
up-to-date GUIs in an
open manner!

Of course, scripting support in form of Nashorn/ECMAScript/Javascript is on 
board of modern Java
distributions, however there are many more javax.script scripting languages 
available. (In my case I
am very interested in ooRexx, the opensource version of IBM's Open Object Rexx, 
which is a very easy
to learn, yet powerful OO language, and am the author of the JSR-223 
implementation of ooRexx, which
will be included in the next distribution of BSF4ooRexx which is a bridge 
between ooRexx and Java.)

While evaluating the possibilities (for non-informatic students) of taking 
advantage of the JavaFX
infrastructure, I have been experimenting and exploring the JavaFX 
infrastructure. Being acquainted
with the details of javax.script/JSR223 it has been very interesting to learn 
how javax.script is
being deployed on JavaFX. Basically, using SceneBuilder and then manually 
editing the FXML file it
becomes possible to run any scripting programs from (I assume FXMLLoader), 
given that there is a
processing instruction like e.g.



or



which causes FXMLLoader to load the denoted scripting language by name. As a 
result all script code,
be it defined in fx:script elements with a source attribute pointing to the 
file containing the
script code or any code supplied in attributes like "onAction" will be executed 
with this denoted
scripting engine.

This is it. Nothing else is currently available. Not even employing 
javax.script programming
languages in the context of a WebView/WebEngine, although HTML defines a "type" 
attribute for the
"script" element!

E.g, it is not possible to employ more than one script language for the same 
document, although this
is plain easy! Or, it is not possible to have script controllers defined (only 
Java controllers) in
SceneBuilder. Or it is not possible to use javafxpackager to create a jar-file 
with pure
javax.script code and JavaFX resources, as there is no support to denote a 
script to be used as the
"main class".

---

As this is the JavaFX developer list, I would like to propose in this e-mail 
very few and (really!
:) ) easy to implement enhancements that immediately would increase the 
usability and the
attractiveness of JavaFX for script writers. If there is an official tracker 
infrastructure where I
could post at least the simple enhancements, please advise!

---

 1. Suggestion # 1: wherever script code can be denoted, allow a "type" 
attribute with the mime type
value of the javax.script engine to be used to execute the script code. 
Whenever such a "type"
attribute is found, one can load the respective javax.script engine by 
merely using
javafx.script.ScriptManager.getEngineByMimeType(mimeType) and then have it 
execute the script code.

FXML candidates are the fx:script element itself as well as all attributes 
(like "onAction")
that allow to denote script code. But also in HTML 5 (WebView/WebEngine) 
the script element and
its "type" attribute (cf. ).

  * Examples in FXML-documents:

 

  * Example in any fx-elements that have attributes that allow code:



 2. Suggestion # 2: whenever (probably FXMLLoader, WebEngine) execute 
javax.script code, then please
add the following entries to javax.script.ScriptContext.LOCAL_SCOPE 
javax.script.Bindings:

 1. if the "source" attribute (script-element in HTML 5, fx:script-element 
in FXML) denotes a
file name, then use the key javax.script.Engine.FILENAME and store the 
value of "source" in
the LOCAL_SCOPE Bindings. The scripting engine implementation is then 
able to supply that
name to the script program (e.g. in the case of a runtime error, or for 
debugging purposes),
which currently is not possible.

 2. if arguments are to be passed to the script code, then create a Java 
array object with the
arguments, use the key javax.script.Engine.ARGV and store the Java 
array with it. The
scripting engine implementation is supposed to pass on these arguments 
in the scripting
language's format, which currently is not possible.

As you can see, these are very few suggestions, but for javax.script language 
programmers (no matter
which languages they use and mix) they immediately improve the usability of 
JavaFX tremendeously!

It would be great, if someone would be able and willing to implement these 
little suggestions
(probably in the FXMLLoader and WebEngine classes). If there is anything I 
could do to help, please
let me know (also, if anyone can point me to a formal way of 

Re: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ...

[Rony G. Flatscher]

On 28.11.2016 14:18, Rony G. Flatscher wrote:
> Dalibor,
>
> thank you very much for this link, just posted a comparable question there.
>
> Poking around the questions (many unanswered) posted there, my hopes are not 
> very high to get an
> answer (maybe I am too pessimistic here)...
>
> Again, thank you!
>
> ---rony
As feared/anticipated, there have been no real answers on the pointed out 
Oracle community.

Short of any alternatives, I think that this group is probably the most 
appropriate to discuss
javax.script (part of Java!!) implementation issues and ideas with JavaFX. If 
nothing else, *the*
JavaFX developers hang out here!

Therefore I will try to post a few little things that would tremendeously 
improve JavaFX (FXMLoader
and WebEngine) for any script engine, though the implementation complexity 
would be *quite* simple.

---rony



> On 28.11.2016 13:43, dalibor topic wrote:
>>
>> On 28.11.2016 12:55, Rony G. Flatscher wrote:
>>> So I am wondering whether there is another mailing group (other than this 
>>> one) where questions like
>>> this can be asked
>> There is a JavaFX forum at
>> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later
>>  within the Oracle
>> Community.
>>
>> cheers,
>> dalibor topic

[9] Review request: JDK-8088857 Menu slow to respond after resizing a window multiple times with animation running

[Jim Graham]

JBS: https://bugs.openjdk.java.net/browse/JDK-8088857
webrev: http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.rt.00/

Fix is as we discussed.

I'll investigate applying it to 8u-dev soon...

...jim