Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

RE: Planning for JavaFX.next

+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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

"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

Re: Planning for JavaFX.next

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

RE: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

@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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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 -

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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,

Re: Planning for JavaFX.next

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

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.

Re: Planning for JavaFX.next

+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

Re: Planning for JavaFX.next

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:

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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

Re: Planning for JavaFX.next

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