<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi John,<div><br></div><div>Thank you very much for your reply. I think you are actually talking about two problems:</div><div><br></div><div>For compact storage, I think the first choice would be something like PixelBuffer. Pixels can be stored in MemorySegment.</div><div>When the pixel format needs to be converted, it is easier to accelerate using SIMD instructions, which should have better performance.</div><div><br></div><div>For general image I/O, I don't think an intermediate format is necessary, at least not to store the entire image.</div><div>I think we can provide an ImageBuilder interface, and the actual implementation stores pixels in the same way as the Image implementation.</div><div>When reading an image, the pixels can be written directly into the ImageBuilder.</div><div>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, </div><div>and there is no need to read the entire image in advance.</div><div>Finally, the internal structure of ImageBuilder can be reused directly to create an Image without copying or converting it again.</div><div><br></div><div>However, this is just a rough idea, and there are still many problems to be solved, such as color space, </div><div>background loading, progressive loading, animated images, motion photos, etc.</div><div><br></div><div>Glavo</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 17, 2025 at 3:35 AM John Neffenger <<a href="mailto:john@status6.com" target="_blank">john@status6.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <div>On 4/16/25 3:04 AM, Glavo wrote:<br>
    </div>
    <blockquote type="cite">
      <div>* Different image APIs have to repeatedly implement support
        for reading the same image format (such as JPEG).</div>
      <div>  In fact, AWT, JavaFX, and Android now each implement
        reading JPEG images.</div>
      <div>  This is a waste.</div>
    </blockquote>
    <p>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.<br>
    </p>
    <p>The challenge is not just in reading various external image
      formats. There are three parts:<br>
    </p>
    <ol>
      <li>Efficiently loading and converting an image from an external
        format (GIF, PNG, JPG).<br>
      </li>
      <li>Efficiently storing images internally with a minimal number of
        bits per pixel.</li>
      <li>Efficiently converting the internal format to that required by
        the client library (AWT, JavaFX, Android).</li>
    </ol>
    <p>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.</p>
    <p>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.</p>
    <p>JavaFX provides an AWT-to-JavaFX image conversion utility, called
      <a href="https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingFXUtils.java" target="_blank">SwingFXUtils::toFxImage</a>,
      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 <a href="https://github.com/jgneff/tofximage" target="_blank">different
        ways to convert</a> 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 <a href="https://jgneff.github.io/tofximage/2020-06/" target="_blank">much faster
        than the others</a>.</p>
    <p>A common library might end up too generic, too slow, or require
      too much memory to be useful.<br>
    </p>
    <p>John<br>
    </p>
  </div>

</blockquote></div>