In my case (1) it is a complex clipping shape that gets created based on an initial rectangle from which the code „subtracts“ a list of ellipses (2). The clip is set on paths so that their rendering stops before they enter the ellipses.
—Dirk (1) https://twitter.com/dlemmermann/status/1474059970857644032 <https://twitter.com/dlemmermann/status/1474059970857644032> (2) https://gist.github.com/5f4f45aa150c23f2e218b48a18d22121 <https://gist.github.com/5f4f45aa150c23f2e218b48a18d22121> > Am 03.01.2022 um 09:34 schrieb John Hendrikx <hj...@xs4all.nl>: > > I tested this, and it seems to still not work quite right. > > As far as I can see, it is not a memory leak, just slow performance when > subtracting many shapes from roughly the same location from another shape. > When the shapes are more spread out, it performs better. > > I don't think it is a major issue, definitely not for regular uses of shapes. > > Doing "game" like graphics is often an exercise to find how an API can be > best exploited to get what you want with good performance; telling an API to > brute-force render 10000 points in a 100x100 grid for example won't perform > well, put them on a texture instead and it will perform well. > > This seems to be a similar case, so I'd recommend to use a Canvas, and draw > circles on that instead. > > --John > > On 02/01/2022 15:56, Eric Bresie wrote: >> Noticed a recent tweet (1) about an older memory leak issue (2) and was >> curious if with recent performance and memory changes if anyone can confirm >> if this is still an issue or if it has been resolved as part of the recent >> changes. There appears to be a test attached to the original issue. >> >> Eric >> >> References: >> (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21 >> >> (2) https://bugs.openjdk.java.net/browse/JDK-8088535 >>
