<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/16/25 3:04 AM, Glavo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com">
<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 moz-do-not-send="true"
href="https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingFXUtils.java">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">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/">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>
</body>
</html>