AWT is somewhat dead, will JavaFX survive?

[Philip Race]

We recognise this as a "gap". Definitely a lot of work to fill it. 
There's also degrees of what people need.
Casual photo editing vs telescopic data or medical imaging etc.
When you get to the data sizes you are talking about, which may require 
image tiling even today,
and the kinds of image filters and processing being  applied, it is 
maybe more a 'server' application as a 'client' one.
So I think we would want headless FX too.

-phil.

On 10/1/24 1:37 AM, Martin Desruisseaux wrote:
> Le 2024-10-01 à 00 h 33, Kevin Rushforth a écrit :
>
>> And yes, we know that that there are missing features in JavaFX 
>> relative to Swing like desktop integration and Image I/O to name two 
>> important ones. I guess the question for you and other app developers 
>> are: which ones are the most important that there be a native JavaFX 
>> solution for?
>
> Just for information (not really expecting this work in JavaFX, since 
> it may be a major effort), one feature is the `java.awt.image` package 
> (I don't know if this is considered included in Image I/O), in 
> particular its capacity to handle Terabytes of Earth Observation 
> raster data. This package was the foundation of Java Advanced Imaging 
> (JAI), designed 25 years ago by Sun Microsystem and Kodak with 
> contributions of peoples from NASA and medical imagery. While JAI is 
> not maintained anymore, we can still develop our own JAI-like 
> framework on top of `java.awt.image`. Despite its age, that package is 
> still amazingly powerful, even compared with modern competitors.
>
> However, `java.awt.image` is complex. Having 25 years of experience in 
> using extensively that package (and contributed a few OpenJDK 
> patches), I think I see how it could be simplified and better 
> integrated with `java.nio.Buffer` (for example) without losing its 
> power. The `java.awt.image` package may contain features that seem 
> obsolete today, such as MultiPixelPackedSampleModel, but those 
> features are important when the images are Gigabytes in size. However, 
> it would be possible for a new image framework to keep those features 
> without "polluting" the public API with those specialized classes.
>
> If an OpenJDK or OpenJFX effort was initiated for designing a 
> successor of `java.awt.image` with the goal of being about as 
> powerful, I would be glad to participate as a volunteer if accepted.
>
>     Martin
>
>