Surface the ImageLoader API

[Kevin Rushforth]

Characterizing a new feature in terms of exposing internal interfaces 
isn't really the right way to think about it. The fact that there might 
be internal classes that do something similar to what you propose isn't 
really relevant (other than later down the road when it comes time to 
discuss the implementation).

Rather you should start with a description of the enhancement you would 
like to see: additional image loading capability, in this case. Then a 
discussion of the API would be in order.

What's really being asked for here is a feature like Java2D's Image I/O 
with pluggable image formats. We spent some time looking at that a few 
years ago. Doing this right would be a very large effort. I wouldn't be 
in favor of a piecemeal approach without understanding the larger picture.

So I don't support this proposal as stated.

-- Kevin


On 6/4/2021 9:39 AM, Michael Strauß wrote:
> I've been trying to add SVG support to a JavaFX application (which is
> the image format I'm encountering most often in app projects), but
> that's quite hard because the ImageLoader API is pretty much closed
> for extension.
>
> I'm proposing to open up the ImageLoader API to enable third-party
> developers to create image loaders for emerging image formats like SVG
> or WebP.
>
> There will need to be some minor API and behavioral changes:
>
>
> 1. `ImageLoader.load` requires a new parameter "pixelScale":
> current: ImageFrame load(int, int width, int height, boolean, boolean)
> new: ImageFrame load(int, int width, int height, double pixelScale,
> boolean, boolean)
>
> This parameter is important for vector image loaders like SVG. If an
> image loader is invoked with `width==0` and `height==0`, the
> implementation should return an image with its natural resolution.
> Vector image loaders need to know the requested pixel scale in order
> to render the image with the correct pixel density.
>
>
> 2. `ImageFormatDescription.Signature` must be able to accept `null`
> values in the byte array:
> current: public Signature(byte...) {...}
> new: public Signature(Byte...) {...}
>
> A `null` value will match any byte at the corresponding position in
> the image file header. This is necessary to match file headers that
> contain variable data, like the WebP image header:
> byte 0-3: 'R', 'I', 'F', 'F'
> byte 4-7: <file size>
> byte 8-11: 'W', 'E', 'B', 'P'
>
> Note that in this example, the corresponding signature description would be:
> { 'R', 'I', 'F', 'F', null, null, null, null, 'W', 'E', 'B', 'P' }
>
>
> 3. Enable file extension matching (in addition to signature matching)
> with the following semantics:
> Any valid `ImageFormatDescription` MUST contain at least one file
> extension, and MAY contain any number of signatures and MIME types (or
> none at all). When `ImageStorage` chooses an image loader for a file,
> it first tries to match the file by signature, and if it doesn't
> match, it tries to match by file extension (or, if the source is a
> "data" URI, it tries to match by MIME type).
>
> The reason for this is that some image formats like SVG cannot be
> meaningfully matched by signature; in this case, the SVG image format
> description would not contain a signature description and would always
> fall back to matching by file extension or MIME type.
>
>
> I'd welcome any opinions on this proposal.