Hello,
Thank you for the clarification.
I thought the width and height in the loader referred to the preferred size.
Since SVG is essentially XML, manipulating it at runtime is straightforward.
We can generate an image at a specific breakpoint and change it using a
data URI.
Additionally, viewport media support will likely provide even more
flexibility.
.pane {
-fx-background-image: url("/image.svg");
}
@media (812px <= width <= 1024px) {
.pane {
-fx-background-image: url("/image-x2.svg");
}
}
I created a demo repository that demonstrates loading and transforming SVG
using the jsvg library.
https://github.com/mkpaz/jsvgfx
Best regards.
пн, 14 июл. 2025 г. в 21:35, Michael Strauß <michaelstr...@gmail.com>:
> A JavaFX Image always has a fixed size. Usually, this will be the
> intrinsic size of the image, but it can also be any other size if the
> image is created with the constructor that takes requestedWidth and
> requestedHeight.
> Internally, the JavaFX Image is stored with an arbitrary pixel
> density. There's exactly two ways how you can end up with a pixel
> density > 1:
> a) use the @Nx image naming convention
> b) use a variable-density image loader on a high-DPI screen
>
> Importantly, you won't get a "dynamic" image if you do that (meaning
> an image that can have different render sizes), you simply get a
> normal JavaFX Image that is loaded with a higher pixel density.
> This means that if you have a variable-density image loader and
> canSetSourceRenderSize() is true, J2DImageLoader scales the intrinsic
> size of the image (or the requested size) with the screen DPI.
>
> A JavaFX Image is not a scene graph node, it doesn't know about where
> it is used and how large it ends up on the screen.
>
> I think what you're asking for is one of two things (or both things at
> once):
>
> 1. Allow multiple versions of an image loaded at the same time, and
> defer selection until render time. Then choose the best version
> depending on the transformed size of the rendered image. This would
> work for discrete versions like you get with the @Nx naming
> convention.
> 2. Allow an image to be dynamically rasterized from source depending
> on the transformed size of the rendered image. This would work for
> variable-density images.
>
> I think that the first option would be a good enhancement. The second
> option seems much harder to achieve.
>
>
>
> On Mon, Jul 14, 2025 at 3:20 PM mkpaz <quizy...@gmail.com> wrote:
> >
> > Hello,
> >
> > I'm testing the new pluggable image API with SVG and noticed one thing.
> > Since SVG is a scalable vector format, it can be rendered at an
> arbitrary size.
> > For this purpose, we need to know the frame (pane) size and scale the
> image accordingly while rendering.
> > As I understand, ImageReadParam is used to pass the frame size to the
> image reader.
> >
> > public class ImageReadParam extends IIOParam {
> > /**
> > * Returns {@code true} if this reader allows the source image to be
> rendered at an
> > * arbitrary size as part of the decoding process ...
> > */
> > public boolean canSetSourceRenderSize() {
> > return canSetSourceRenderSize;
> > }
> > }
> >
> > But when I set canSetSourceRenderSize to true to activate this, I don't
> get the client frame size.
> > Instead, I get the actual image size, which the reader already knows
> since it implements the getWidth() and getHeight() methods.
> >
> > I read the code and came across this:
> >
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/java2d/J2DImageLoader.java#L122
> >
> > Why does the image loader use the reader's width and height in both
> branches?
> > Shouldn't the loader provide the frame size when canSetSourceRenderSize
> returns true?
> > Maybe I'm looking for something that isn't supported? Yet?
> >
> > Best regards.
>
