<AWT Dev> <Swing Dev> javax.swing.RepaintManager volatileMap

[Artem Ananiev]

Hi, Vladimir,

have you received this reply, or it was lost for some reason?

Thanks,

Artem

On 8/28/2013 5:52 PM, Artem Ananiev wrote:
> Hi, Vladimir,
>
> I agree that using a class with no equals/hashCode overridden as a key
> for HashMap is not the best thing to do. However, in this case the
> problem seems to be caused by something else.
>
> I'm not an expert in RepaintManager, but here is what I observe:
>
> 1. When graphics environment changes, we get displayChanged()
> notification (it's not a public API yet, unfortunately).
>
> 2. RepaintManager.displayChanged() clears all the volatile images, as
> they depend on the GraphicsConfiguration objects and may be invalid
>
> 3. In clearImages(), we iterate through volatileMap and remove the
> images. Note that despite GraphicsConfiguration doesn't override
> equals/hashCode, iteration should still work.
>
> Anyway, it indeed looks like a bug, no matter of what it's caused by. Do
> you have a test case that can be used to reproduce it, other than to run
> JDeveloper?
>
> Thanks,
>
> Artem
>
> On 8/28/2013 3:00 PM, Vladimir Sitnikov wrote:
>> Hi,
>>
>> In the heapdump of SQL Developer 4.0 I found that RepaintManager holds
>> 23 items of sun.awt.image.BufImgVolatileSurfaceManager 5-10MiB each.
>>
>> All the images are contained in "volatileMap" HashMap.
>>
>> I identified that the key of the map is sun.awt.Win32GraphicsConfig and
>> that class does not override equals/hashCode.
>>
>> Can you please tell me if "using GraphicsConfig as a key knowing the
>> fact this key does not ovveride equals/hashCode" is intentional or not?
>>
>> I have checked several keys of the map (Win32GraphicsConfig) and they
>> have identical value (even screen and sTypeOrig references point to the
>> same objects), however as the Win32GraphicsConfig objects itself are
>> different java objects they occupy different entries in valueMap.
>>
>> --
>> Regards,
>> Vladimir Sitnikov