Surface the ImageLoader API
Michael Strauß
michaelstrau2 at gmail.com
Fri Jun 4 22:10:23 UTC 2021
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 images
- reading or writing metadata
There's Java2D for that, no need to duplicate existing functionality.
For its intended purpose, I do think that the existing internal
implementation is actually a good API, because it is geared towards
the problem that it is trying to solve.
Expanding the scope of the existing feature to include any of these
additional things doesn't seem like a sensible idea to me.
I would like to understand whether you disagree with my assessment of
the intended purpose of this feature.
Do you think that there is a "larger picture" that would change the
goals and non-goals?
You seem to imply that extending the existing feature is the wrong
approach, and that there is a better approach which requires more
effort.
Can you share any of insights that lead to this conclusion? I haven't
been able to find this information in JBS.
Am Fr., 4. Juni 2021 um 22:03 Uhr schrieb Kevin Rushforth
<kevin.rushforth at oracle.com>:
>
> 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
More information about the openjfx-dev
mailing list