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....@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 > >
