Hi John, Thank you very much for your reply. I think you are actually talking about two problems:
For compact storage, I think the first choice would be something like PixelBuffer. Pixels can be stored in MemorySegment. When the pixel format needs to be converted, it is easier to accelerate using SIMD instructions, which should have better performance. For general image I/O, I don't think an intermediate format is necessary, at least not to store the entire image. I think we can provide an ImageBuilder interface, and the actual implementation stores pixels in the same way as the Image implementation. When reading an image, the pixels can be written directly into the ImageBuilder. Writing pixels one by one may result in a performance loss, but only one row or one block of pixels need to be cached for batch writing, and there is no need to read the entire image in advance. Finally, the internal structure of ImageBuilder can be reused directly to create an Image without copying or converting it again. However, this is just a rough idea, and there are still many problems to be solved, such as color space, background loading, progressive loading, animated images, motion photos, etc. Glavo On Thu, Apr 17, 2025 at 3:35 AM John Neffenger <j...@status6.com> wrote: > On 4/16/25 3:04 AM, Glavo wrote: > > * Different image APIs have to repeatedly implement support for reading > the same image format (such as JPEG). > In fact, AWT, JavaFX, and Android now each implement reading JPEG images. > This is a waste. > > I was initially frustrated by the split between Java (AWT) and JavaFX in > their image support and would have welcomed a common library, but I came to > appreciate the flexibility of having both available in a JavaFX > application. Below are some thoughts. > > The challenge is not just in reading various external image formats. There > are three parts: > > 1. Efficiently loading and converting an image from an external format > (GIF, PNG, JPG). > 2. Efficiently storing images internally with a minimal number of bits > per pixel. > 3. Efficiently converting the internal format to that required by the > client library (AWT, JavaFX, Android). > > The first item is determined by the external image format standards, but > the second and third items involve a trade-off. Optimizing for memory usage > might results in a huge waste of CPU time doing conversions, while > optimizing for zero conversion time might results in a huge waste of RAM. A > JavaFX application can pick and choose between this trade-off by using both > the AWT and JavaFX image libraries. > > For example, I had to load and display hundreds of binary images (pure > black and white) on a constrained device. The AWT can store images in > memory as one bit per pixel, but JavaFX supports only 32-bit images. So I > needed to use the AWT image format in memory, but the JavaFX image format > for display, converting them on-the-fly one-by-one to 32 bits per pixel. > > JavaFX provides an AWT-to-JavaFX image conversion utility, called > SwingFXUtils::toFxImage > <https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingFXUtils.java>, > but I couldn't use it because it was far too slow. It's slow because it's > generic and has to work for all image types. I came up with 14 different > ways to convert <https://github.com/jgneff/tofximage> an AWT image to a > JavaFX image: 9 that work for images with transparency and another 5 that > work only for images with no alpha. In my case, one such conversion was much > faster than the others <https://jgneff.github.io/tofximage/2020-06/>. > > A common library might end up too generic, too slow, or require too much > memory to be useful. > > John >
