JavaFX and OpenGL

[Nikos Nikolos]

Hello all,



Following the thread
http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020025.html
I would like to ask for more information on JavaFX plan to allow a simple
way to use existing OpenGL code.



I know this is not a new question and please forgive me if I’ve overlooked
some answers already posted.



I work in the niche area where desktop applications are still needed and
use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that
try to figure out how we can use JavaFX without a huge performance drop. I
think this bug https://bugs.openjdk.java.net/browse/JDK-8091324 is the best
summary of potential needs. And the answer gave by Kevin Rushforth was
quite disappointing.



I remember Swing teams members (Kenneth Bradley Russell) working hard to
have a nice way to use OpenGL in a platform independent manner which is one
of the strength of Java. JOGAMP team also made a good work more recently.



Some tricks have been used to try to provide a solution:

· https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2

· https://github.com/pepe1914/jfx-zoglpipeline

· https://www.youtube.com/watch?v=aYRF34UYu-E

But they are very fragile (use of internal classes, rebundling JavaFx
jars…).



Is this need too specific for a change to have it implemented in JavaFX?

Going on with Swing is a potential solution but it won’t resist a
comparison with QT long.



Thanks for any of your ideas on that.

Regards

[9] Review request: JDK-8170883 Add Class Path to Examples

[Chris Bensen]

Kevin, Victor,

Please review changes to the Java Packager examples and a new example mixing 
modular jars and non modular jars.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170883 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170883/webrev.00/ 


Chris

[9] Review request: JDK-8168407 javapackager throws "java.lang.ClassNotFoundException: testapp.util.Util" when bundle is built through ANT for unnamed module depending on named module scenario

[Chris Bensen]

Kevin,

Please review this change to allow a non modular jar main app to use and bundle 
modular jars into the runtime image.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8168407 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8168407/webrev.00/ 


Chris

[9] Review request for 8170930: WebView unit test crashes in 32-bit mode

[Murali Billa]

 

Hi Kevin,


Please review the backout fix for JDK-8164792.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170930


Webrev: http://cr.openjdk.java.net/~mbilla/8170930/webrev.00/

 


Thanks,

Murali

Re: Planning for JavaFX.next

[David Eisner]

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

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

-David

On Wed, Dec 7, 2016 at 6: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

[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


On 08.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

[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-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
> Of Jonathan Giles
> Sent: Thursday, December 08, 2016 12:45 AM
> To: openjfx-dev@openjdk.java.net
> Subject: Planning for JavaFX.next
> 
> Hi folks,
> 
> Development on JDK 9 is slowly starting to ramp down, and we are starting to
> turn our attention to the goals for JavaFX in JDK 10 and beyond. We are
> starting to compile our list of what we think is important, but we really 
> want to
> hear from the community about what their highest priorities are to them. As
> always, it's important to keep in mind what JavaFX is (e.g. it isn't aiming 
> to be a
> high-performance game engine), but even still there are bound to be a
> number of places where people might want to weigh in, for example:
> 
>   * New layout containers (e.g. Flexbox)
>   * Public APIs for UI control behaviors
>   * Marlin renderer enabled by default
>   * Support for CSS animations
>   * CSS performance improvements
>   * TableView improvements (cell spanning, row / column freezing, etc)
>   * TableView performance
>   * Focus traversal API
>   * WebGL support in WebView
>   * Improved image I/O support
>   * A JavaFX equivalent of the AWT Desktop APIs
>   * Multi-res image API
>   * NIO-backed writable images
> 
> If there are other areas of interest that aren't listed here, please start
> discussing them and we can work together to determine priorities.
> If all you want to do is add a +1 for one of more of the items above, even 
> that
> will be very useful.
> 
> Thanks,
> -- Jonathan

Re: Planning for JavaFX.next

[Tom Eugelink]

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

Tom


On 8-12-2016 15:09, Jeff Martin wrote:

Be wary of selection bias 
 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


On Dec 7, 2016, at 5: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

[Michał Zegan]

Are there any plans for adding accessibility to linux systems?
> On 8/12/2016 0: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

[Jeff Martin]

Be wary of selection bias 
 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

> On Dec 7, 2016, at 5: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

[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

Am 08.12.16 um 00:45 schrieb 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

AW: Planning for JavaFX.next

[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-boun...@openjdk.java.net] Im Auftrag von 
Jonathan Giles
Gesendet: Donnerstag, 8. Dezember 2016 00:45
An: openjfx-dev@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,
-- Jonathan

Re: Planning for JavaFX.next

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

2016-12-08 10:22 GMT+01:00 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

Re: Planning for JavaFX.next

[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

Re: Planning for JavaFX.next

[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

Re: Planning for JavaFX.next

[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 Software Manager
t: (+44)203 668 9870




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.