JDK-8088535 Memory Leak

[Dirk Lemmermann]

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 <hjohn at 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
>>