prism.maxvram limitation
Michael Strauß
michaelstrau2 at gmail.com
Thu May 23 16:19:58 UTC 2024
I wonder why there's a software-defined limit in the first place,
given that there doesn't seem to be a way for JavaFX to gracefully
handle failed texture loads.
You say that the limit is reasonable for GPUs, but why is this any
different from system memory? GPUs come in all different kinds of
sizes, why is 512 MB any more significant than 256 MB or 8 GB? It's an
arbitrary value that might be too small for some systems, and too
large for other systems.
Right now, JavaFX simply bugs out when the limit is reached. Unless a
graceful degradation capability is added, I suggest to remove the
limit entirely and let JavaFX bug out when the actual hardware limits
are reached.
On Tue, May 14, 2024 at 4:14 PM Eduard Sedov <eduard.sdv at web.de> wrote:
>
> Hi all,
>
> There is a long-lived bug in JavaFX: JDK-8089112: Need to handle the case of a failed texture load when rendering large images
>
> JavaFX manages a pool of resources that is limited to 512Mbytes by default. This limit can be increased by setting the 'prism.maxvram' system property.
>
> This limit is reasonable for the GraphicsPipelines (the D3DPipeline and the ES2Pipeline) that are backed by a graphics device that has such a limitation.
>
> But it does not make sense for pipelines that use only the main memory: the J2DPipeline and perhaps the SWPipeline.
>
> The J2DPipeline is currently used for printing. For example, printing an image on Letter paper using 600PPI printer requires 134_640_000 bytes. When the printed image is redirected to a PDF printer, even higher resolution is needed to get adequate quality because the PDF can zoom in. This often exceeds the limitation and ends in a NullPointerException if the allocated textures exceed the specified maxvram value.
>
> There is no way to specify different values for each pipeline or to remove the limitation for software pipelines.
>
> I would add this possibility? What do you think?
>
> Thanks,
> Eduard
>
>
More information about the openjfx-dev
mailing list