Two thoughts come to mind.
1. While I agree that it isn't necessary to do everything all at once, I
don't agree that a full featured Image I/O API is off the table as a
future enhancement. Whatever you end up proposing to do here should
ideally fit into what we would want to do in the future i
Let me restate my intentions to be more clear:
What I'm asking for is a feature to support third-party image format
plugins, with the intention of decoding images for use in the JavaFX
scene graph.
I think the following things should remain explicit non-goals:
- writing images
- transcoding image
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
I should note that these proposed changes were sufficient for me to
implement an SVG image loader and a WebP image loader using
third-party libraries.
