Planning for JavaFX.next

[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


On 8-12-2016 08:04, Matthew Elliot wrote:
> +1 for CSS perf (diagnostic tooling for slow selectors like @Daniel Gloeckner referenced earlier would also be a bonus)
> + for scene graph rendering perf
> + table perf
> + table features and fixes (column freezing, row span, selection model fixes and memory leak fixes)
> + integration of controlsfx into JFX.
>
> Matt.
>
> Sent from my phone.
>
>> On 8/12/2016, at 7:07 AM, Chris Newland <cnewland at chrisnewland.com> wrote:
>>
>> Hi Jonathan,
>>
>> +1 to that list for me.
>>
>> In my experience JavaFX performs well for the "low-level" (Canvas +
>> GraphicsContext) stuff with one exception - the PixelWriter APIs appear do
>> a lot of array duplication and copying under the hood which I believe can
>> be optimised. I'll investigate further and try to come up with a patch.
>>
>> Nice to have (but lower priority than everything on the list) would be a
>> public API for grabbing frames from a MediaPlayer which used to be
>> possible in 8 with player.impl_getLatestFrame().
>>
>> Echoing Tom and Felix, my #1 priority would be fixing scenegraph
>> performance as tables with large row counts and charts (e.g. XYChart) with
>> large numbers of data points (e.g. 50K) in their Series can easily lead to
>> multi-second render times and huge heap usage.
>>
>> Thanks for opening this discussion,
>>
>> Chris
>>
>>> On Wed, December 7, 2016 23:45, Jonathan Giles wrote:
>>> Hi folks,
>>>
>>>
>>> Development on JDK 9 is slowly starting to ramp down, and we are
>>> starting to turn our attention to the goals for JavaFX in JDK 10 and
>>> beyond. We are starting to compile our list of what we think is important,
>>> but we really want to hear from the community about what their highest
>>> priorities are to them. As always, it's important to keep in mind what
>>> JavaFX is (e.g. it isn't aiming to be a high-performance
>>> game engine), but even still there are bound to be a number of places where
>>> people might want to weigh in, for example:
>>>
>>> * New layout containers (e.g. Flexbox)
>>> * Public APIs for UI control behaviors
>>> * Marlin renderer enabled by default
>>> * Support for CSS animations
>>> * CSS performance improvements
>>> * TableView improvements (cell spanning, row / column freezing, etc)
>>> * TableView performance
>>> * Focus traversal API
>>> * WebGL support in WebView
>>> * Improved image I/O support
>>> * A JavaFX equivalent of the AWT Desktop APIs
>>> * Multi-res image API
>>> * NIO-backed writable images
>>>
>>>
>>> If there are other areas of interest that aren't listed here, please
>>> start discussing them and we can work together to determine priorities. If
>>> all you want to do is add a +1 for one of more of the items above, even
>>> that will be very useful.
>>>
>>> Thanks,
>>> -- Jonathan
>>>
>>>