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

[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

Post by Jonathan Giles
Hi folks,
* 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

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

Post by Jonathan Giles
Hi folks,
* 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

[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

Post by 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.

Post by 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
* 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

[Tom Eugelink]

Well, a lot of people already have made suggestions. For me the focus-lost issue is a very important thing. But more exotic is the easy data entry; this is something that for administrative applications is a real gain (and where is Java used a lot?). I had to hammer JTable into obedience to get it working in the the current Swing based application. It comes down to being able -like in MSaccess- to quickly enter data in cells; type amount, hit-enter-on-the-number-pad, type articlenr, hit-enter-on-the-number-pad, automatically a new row is added, type amount, ... You get the flow.

I'm going to wrap up my ResponsivePane first. Functionally it is complete, but it needs fine tuning, tests, documentation and of course one or two blog posts. And then I'm going to pain myself with J9 and then upgrading TestFX. I'll keep you informed.

About FlexBox, and I'll be writing a blog on this, in web applications is it custom to work based on a certain width and then assume unlimited vertical space through a scrollbar. I think that in a normal application this is not the UI that users expect, but they also expect a fixed height and then some dynamic layout with lists and tables within. Take a minute and imagine some applications you are using; even a webbrowser has a given width and height, with a webview inside doing the scrolling. So I'm taking a different approach with ResponsivePane. Not sure if it is the correct or best, but it is working well for my time registration testapp. I'm not seeing FlexBox happing for applications.

Tom

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

Post by 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.

Post by Jonathan Giles
Hi folks,
* 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

[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

Post by 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.

Post by 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
* 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

[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

Post by 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
* 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

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

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

Post by 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
* 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

[Tom Eugelink]

If you would integrate ControlsFX with JavaFX, it would bind to its release cycle and policies as well. Having ControlsFX (or my JFXtras) as a separate project, allows for much more flexibility. So I would really not do that. Nope.

Tom

Post by Matthew Elliot
+ 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.

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

Post by 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
* 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

[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

Post by 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
* 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

[Johan Vos]

+1 on CSS and SG performance improvements. They are very tightly coupled
(e.g. lots of SG-related calls during CSS pass and lots of redundant CSS
processing during layout pass) so either they get decoupled, or they stay
like is, but then performance improvements require cross-team work.

- Johan

Post by 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
* 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

[Dell Green]

Hi There,

Apologies if the following seems trivial or thats has already been done but:

For our business and customers, we really would like support for having a single jar file that contains jar dependencies and native libraries, without using third party tools, writing custom loaders etc.
It should be possible to have a single jar artefact that re-enforces “write once run anywhere” with its dependencies containing within and available on the class path, a bit like a war file
I appreciate the jvm cannot be contained within and thats fine I’ll use native packing for this.

Up to now we have had to use third party solutions, like fatjar, onejar, jna etc, or decompress jars and include class files into main jar.
Now I know people are going to shout ’native packaging’ etc, but most of our products just contain java code, and it seems unnecessary complication in most our our deployments to set up our build servers to build on mac, linux and windows just to include a native artefact for each platform, when the actual runtime code doesn't care what platform it is on.
We do use all these methods across a whole range of products but it would be nice to have the option of producing a self contained jar file to send to our field team regardless of what platform they are on.

Supplying zips with jar and libs folder in it has proven to be problematic with on more than one occasion our field engineers, rightly or wrongly thinking the jar is the executable and taking that from the zip and leaving the everything else behind.

Once again apologies if the is functionality is now already available or coming in java9 that I am not aware of.



Dell Green
R&D Software Manager
t: ([phone]




206 Great Portland Street
London W1W 5QJ


Ideaworks (London) Ltd is a company registered in England and Wales, Company Registration no: 3943726. Registered office: 206 Great Portland Street, London, W1W 5QJ. This email and its contents are confidential. If you have received this message in error, please notify us and delete it. Any views presented in this email are solely those of the author and do not necessarily represent those of the company.

[Dirk Lemmermann]

I have these priorities regarding the items mentioned by Jonathan:

“Put the pedal to the metal” section:
+1 CSS performance improvements
+1 TableView performance
+1 Marlin renderer enabled by default

“The rest” section:
+1 TableView improvements (cell spanning, row / column freezing, etc)
+1 Focus traversal API
+1 A JavaFX equivalent of the AWT Desktop APIs

—Dirk

http://www.dlsc.com

[Erik De Rijcke]

On of the major problems we have here using javafx is the the extremely
slow loading speed of the fxmls (we have about 15000+ arm cortex devices
running javafx in production). Sure, there is a lot to gain in manually
optimizing and reducing the number of nodes and whatnot, but that kinda
beats the purpose of having fast development cycle using jfx. As an
experiment we used a rather unkown/obscure fxml precompiler and noticed a
speed gain of 10s (worst case fxml) -> 0.1s!

My proposal is thus to absolutely have an fxml precompiler as the speed
gains are tremendous on slower devices.

Further I would +1 the CSS performance.

Another major hurdle we had was the complete inability to inter-operate
with any native hw acceleration (OpenGL ES2 to render a GPS navigator
inside the jfx app to be precise). Sure I understand the need to abstract
things away given that the user/programmer should not notice what platform
he's running on. In reality it is often very well known which platform will
be used. It would be nice to at least have some handles (through JNI?) to
use the existng jfx rendering context and issue your own custom gl
commands. Now we ended up rendering in a separate context and doing a
glreadpixels, copy that to the java/jfx side and render to an image.
Needless to say the performance is shi^H^H^H not good.

In general would say to have a look at your main competitor (Qt-gui imho),
see what jfx does well and make sure it keeps doing that, and see what
Qt-gui does better (speed, qml, native api exposure, wayland support to
name a few) and improve upon that.

Post by Dirk Lemmermann
+1 CSS performance improvements
+1 TableView performance
+1 Marlin renderer enabled by default
+1 TableView improvements (cell spanning, row / column freezing, etc)
+1 Focus traversal API
+1 A JavaFX equivalent of the AWT Desktop APIs
—Dirk
http://www.dlsc.com

[Dirk Lemmermann]

I would like to see support in Canvas for hardware accelerated shift of its current content.
Something similar to the JViewport “blitting” feature in Swing.

Dirk

[Keimel, Christoph]

Hello,

from our perspective as business application developers we would love to see:

1) CSS performance improvements
2) TableView and TreeTableView improvements - especially a cell spanning feature would be most helpful to create better tree tables

Thanks,
Christoph


-----Ursprüngliche Nachricht-----
Von: openjfx-dev [mailto:openjfx-dev-***@openjdk.java.net] Im Auftrag von Jonathan Giles
Gesendet: Donnerstag, 8. Dezember 2016 00:45
An: openjfx-***@openjdk.java.net
Betreff: Planning for JavaFX.next

Hi folks,

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

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

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

Thanks,
-- Jonatha

[Michael Paus]

There once was something called "Project Butter" for Android and
I would like to see something similar for JavaFX too. The goal should
be to make all user interactions with a JavaFX GUI as butter-smooth
as users expect them to be and as you can observe them in native
software. More specifically I'd like to see:

- general SG/CSS performance improvements
- more accurate rendering (double vs. float)
- use multi-threaded rendering with marlin renderer
- improved scrolling on touch devices
- hw-accellerated shifting of rectangular regions of a canvas
- better integration of external rendering engines into JavaFX (OpenGL,
Media players, ...)

Michael

Post by 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
* 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

[Anthony Vanelverdinghe]

Hi Jonathan

Personally, I'd love to see
* some particular media enhancements, namely audio device enumeration
and selection [1] and support for keyboard "multimedia keys" [2]
* TabPane improvements to be on a par with browsers (support for
reordering/dragging [3], having a close button on all tabs, allow to
"middle-click close" non-active tabs, etc.)

[1] https://bugs.openjdk.java.net/browse/JDK-8091008
[2] https://bugs.openjdk.java.net/browse/JDK-8090319
[3] https://bugs.openjdk.java.net/browse/JDK-8092098

Kind regards
Anthony

Post by 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
* 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

[Michał Zegan]

Are there any plans for adding accessibility to linux systems?

Post by 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
* 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

[Jeff Martin]

Be wary of selection bias <http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/> when asking advice from us on this list. I would advocate a feature based on who *isn’t* using JavaFX: WebAssembly browser support.

JavaFX is great if you need to build a battleship class app - something big and specialized enough that devs don’t mind packaging/signing/deployment issues and users don’t mind downloads and security issues. It’s not as attractive for smaller scale apps. And most battleship class apps start as smaller apps.

With very little resources, I was able to use a JavaFX/Swing based UI kit and TeaVM to build apps that run on the desktop and in the browser. I would think Oracle would be able to nail this with moderate effort - particularly with WebAssembly coming out this year. Hire/buy the TeaVM guy - he’s brilliant.

The JavaFX team has done something like this before: JavaFXPackager - a feature so useful and needed that it became part of the whole system. I’m not sure we need new table features or such. If someone is going to write a spreadsheet, they’d be better off rolling their own super-table, etc.

http://reportmill.com/snaptea/BusyBox/

jeff

Post by Jonathan Giles
Hi folks,
* 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

[Tom Eugelink]

@Jeff: You may find the jpro.io approach interesting for running apps in the webbrowser.

Tom

Post by Jeff Martin
Be wary of selection bias <http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/> when asking advice from us on this list. I would advocate a feature based on who *isn’t* using JavaFX: WebAssembly browser support.
JavaFX is great if you need to build a battleship class app - something big and specialized enough that devs don’t mind packaging/signing/deployment issues and users don’t mind downloads and security issues. It’s not as attractive for smaller scale apps. And most battleship class apps start as smaller apps.
With very little resources, I was able to use a JavaFX/Swing based UI kit and TeaVM to build apps that run on the desktop and in the browser. I would think Oracle would be able to nail this with moderate effort - particularly with WebAssembly coming out this year. Hire/buy the TeaVM guy - he’s brilliant.
The JavaFX team has done something like this before: JavaFXPackager - a feature so useful and needed that it became part of the whole system. I’m not sure we need new table features or such. If someone is going to write a spreadsheet, they’d be better off rolling their own super-table, etc.
http://reportmill.com/snaptea/BusyBox/
jeff

Post by Jonathan Giles
Hi folks,
* 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

[Jeff Martin]

I’m very excited about Jpro (and awaiting details) - it’s very cool! I still assume deployment is somewhat demanding though, since devs need to provide a virtual CPU and robust network connection for each user. Not as simple as copying a WASM/JS file to a website.

jeff

Post by Tom Eugelink
@Jeff: You may find the jpro.io approach interesting for running apps in the webbrowser.
Tom

Post by Jeff Martin
Be wary of selection bias <http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/> when asking advice from us on this list. I would advocate a feature based on who *isn’t* using JavaFX: WebAssembly browser support.
JavaFX is great if you need to build a battleship class app - something big and specialized enough that devs don’t mind packaging/signing/deployment issues and users don’t mind downloads and security issues. It’s not as attractive for smaller scale apps. And most battleship class apps start as smaller apps.
With very little resources, I was able to use a JavaFX/Swing based UI kit and TeaVM to build apps that run on the desktop and in the browser. I would think Oracle would be able to nail this with moderate effort - particularly with WebAssembly coming out this year. Hire/buy the TeaVM guy - he’s brilliant.
The JavaFX team has done something like this before: JavaFXPackager - a feature so useful and needed that it became part of the whole system. I’m not sure we need new table features or such. If someone is going to write a spreadsheet, they’d be better off rolling their own super-table, etc.
http://reportmill.com/snaptea/BusyBox/
jeff

Post by Jonathan Giles
Hi folks,
* 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

[Daniel Glöckner]

Hi,

Thanks for collecting feedback!

* TableView / TreeTableView: freezing columns (standard in many business apps)
* TableView: in "data grid" scenarios it would be nice if the table would provide an API similar to the one in Swing ("void setValueAt(Object aValue, int rowIndex, int columnIndex)")
* Focus traversal API -> I think this must be done one day ;)

Kind regards,
Daniel

-----Original Message-----
Of Jonathan Giles
Sent: Thursday, December 08, 2016 12:45 AM
Subject: Planning for JavaFX.next
Hi folks,
Development on JDK 9 is slowly starting to ramp down, and we are starting to
turn our attention to the goals for JavaFX in JDK 10 and beyond. We are
starting to compile our list of what we think is important, but we really want to
hear from the community about what their highest priorities are to them. As
always, it's important to keep in mind what JavaFX is (e.g. it isn't aiming to be a
high-performance game engine), but even still there are bound to be a
* 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

[Rony G. Flatscher]

As no one else has asked for it, here it goes: improve javax.script support beyond the e-mail in
this list from 2016-12-07, entitled "RFE/Suggestions to improve JavaFX deployment of javax.script
(part of Java) engines and script code" by:

* introudcing the possibility to define javax.script controllers,
* employing javax.script.Invocable.getInterface(...) to become able to use javax.script code
(objects) to implement the methods/functionality of any Java interface class, especially those
that in the context of JavaFX are of paramount interest: any action, change handlers and the
like (i.e. having script code employed for implementing javafx.event.EventHandler,
javafx.beans.value.ChangeListener, javafx.util.Callback, ...)
* enhance SceneBuilder such that it can be used for defining these new javax.script features
(defining javax.script controllers, code, determining which script object is to be uesed for
Listeners etc.) , maybe allow configurable plugins for javax.script related editors to ease coding
* enhance javafxpackager to allow standalone jars to be created that use a javax.script as the
main class/program to be run, such that no Java sourcecode would be needed to create full-blown
JavaFX applications in javax.script languages
* and ceterum censeo: allow any mix of javax.script code in FXML and HTML documents (FXMLLoader,
WebEngine, and the like), where specific languages get identified by a "type" attribute and
supply FILENAME and ARGV in the local ScriptContext, cf. other e-mail.

Again, please do not underestimate the importance of scripting languages for other programmers than
yourself (you all would probably solve any problem in this area with Java right away, which is fine;
but do not forget that not everyone is a Java-savvy programmer, but excellent in one of the many
available javax.script languages). Adding these javax.script related features is feasible and
actually not that difficult or effortful, yet you would really open up a huge stage ;) for script
programmers ...

---rony

Post by 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
* 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

[David Eisner]

"TableView improvements (cell spanning, row / column freezing, etc)"

+1. Especially row and column freezing. And thanks for soliciting feedback.

-David

Post by 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
* 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

[Laurent Bourgès]

Hi,

I would like to promote performance & quality improvements on the
rasterizer that I could do in jdk10 within a tiger team focused on fx
rendering:

- multithreaded rendering (Marlin is thread-safe) ie the javafx could do
parallel rendering of layers or shapes
- software rasterizers: optimize inner / outer strokes, clipping in
particular for dashes, intersection of curves with scanlines (integer maths)
- rendering quality: use exact pixel coverage (agg approach), gamma
corrected blending
- in general: optimize array/buffer copies and memory allocations in the
complete javafx stack (jvmstat + profiling)
- use value types and more generally, enjoy vahalla, panama integration to
improve java and c code in the rendering pipeline
- gpu / shader upgrade ?

Finally all these items represent an important workload that need both
Oracle and OSS contributors = manpower.
The main issue consists in building a team with new contributors. Maybe
some Oracle or OpenJDK sponsorship is needed to fund such team ie donate
some money for some contributions... at least to organise meetings.

Let me cite the GNU philosophy:
Thus, “free software” is a matter of liberty, not price. To understand the
concept, you should think of “free” as in “free speech,” not as in “free
beer”.

Cheers,
Laurent

[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

Post by 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
* 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

[Nikos132]

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

Post by Matthieu BROUILLARD
Hi Folks,
for us in my company I would said the most important topics are related to
* 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

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

Post by Jonathan Giles
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

Post by Jonathan Giles
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

Post by Jonathan Giles
* 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

Post by Jonathan Giles
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

[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

Post by Nikos132
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

Post by Matthieu BROUILLARD
Hi Folks,
for us in my company I would said the most important topics are related to
* 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

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

Post by Jonathan Giles
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

Post by Jonathan Giles
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

Post by Jonathan Giles
* 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

Post by Jonathan Giles
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

[Markus KARG]

+1 for CSS performance

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

Regards
-Markus

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

Hi folks,

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

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

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

Thanks,
-- Jonathan

[Abu Abdullah]

- RTSP support for MediaPlayer
- expose gstreamer API for public that allows you to build the pipeline yourself

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

Post by Abu Abdullah
- RTSP support for MediaPlayer
- expose gstreamer API for public that allows you to build the pipeline yourself

[David DeHaven]

Post by Abu Abdullah
- RTSP support for MediaPlayer
- expose gstreamer API for public that allows you to build the pipeline yourself

RTSP was proposed at one point, I think these days supporting something like MPEG-DASH might gain more traction.

If we were to implement arbitrary media sources (via NIO) then a community developed RTSP frontend could emerge... (hint: vote for the underlying feature)

-DrD-

[Wolfgang Zitzelsberger]

Hi,

new features are pretty welcome.

+1 Public APIs for UI control behaviors, very important on the desktop
to support keyboard shortcuts properly, maybe some Action/InputMap too
+1 Focus traversal API
+1 A JavaFX equivalent of the AWT Desktop APIs
+1 CSS performance
+1 CSS animations
+1 Any kind of TableView improvement (especially editing)

Things not mentioned, nice to have:

- CSS layout - see https://www.w3.org/TR/css3-grid-layout
- CSS image modification, e.g. colorizing an image
- Window shape support, currently only possibly by enabling transparency
- however, performance would be better with real shape support

Many thanks,
Wolfgang