<Swing Dev> [9] Review Request: 8144166 [macosx] Test java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java fails

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Mar 22 15:07:17 UTC 2016


On 22.03.16 9:11, Semyon Sadetsky wrote:
> On 3/11/2016 12:40 PM, Sergey Bylokhov wrote:
>> On 11.03.16 9:30, Semyon Sadetsky wrote:
>>> Hi Sergey,
>>>
>>> Could you explain why do you suppose that the icon cannot be requested
>>> more then once between the frame minimize and restore?
>>
>> Every time when the frame is minimized the new
>> AquaInternalFrameDockIconUI is created. Every
>> AquaInternalFrameDockIconUI have its own ScaledImageLabel(which is
>> JLabel). At the beginning this label is initialized by the icon from
>> the cache, and this label is used until the frame is restored(cache is
>> not used).
> What if user requests the dock icon to paint it somewhere else while the
> frame is hidden? Before the fix the user got the same icon image from
> the cache, but after the fix he gets another image because it is being
> re-created on each paint.

After the fix the new image recreated only when the frame is minimized, 
after that the same icon will be used for every repaint action: Because 
we set this image as an icon for ScaledImageLabel and check it to null 
on each repaint:
189         public void paint(final Graphics g) {
190             if (getIcon() == null) updateIcon();

> So it becomes impossible to paint the same
> icon that is shown in the dock currently.

>>
>>>
>>>  > The bug is in the last step. When the frame will be minimized in the
>>> second time, it can have another content. But minimized icon
>>>  > will show the miniature from the previous minimization...
>>> Doesn't it contradict with :
>>>  >    * If the frame will be resized/show the cache will be reset.
>>> ?
>>>
>>> --Semyon
>>>
>>> On 3/10/2016 11:35 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk9.
>>>>
>>>> Problem description:
>>>>  - CompEventOnHiddenComponent test was written not according the
>>>> specification but according an assumption(performance related) - "the
>>>> component should not post move/resize events if no listeners were
>>>> registered". The test creates a JInternalFrame and adds
>>>> ComponentListener to it. No events should come to the listeners,
>>>> because the frame is not resized or moved by the test(except initial
>>>> layout). Initial move/resize events are skipped usually, because
>>>> during initialization there are no any listeners. But this is not the
>>>> case in Aqua. AquaInternalFrameDockIconUI adds a listeners to the
>>>> JInternalFrame during initialization -> move/resize events are posted
>>>> -> the test adds own listeners -> events dispatched -> the test
>>>> listeners called -> boom.
>>>>
>>>> According above description the bug could be closed as not a defect.
>>>> But I found another related problem in the AquaInternalFrameDockIconUI.
>>>>
>>>>  - These component listeners in AquaInternalFrameDockIconUI are used
>>>> to maintain the cache of image for the dock(the icon which is used
>>>> when the internal frame is minimized). The logic is next:
>>>>    * Before the frame will be minimized it draws to the special
>>>> ImageIcon which will be used as an icon for the dock.
>>>>    * After the frame is minimized and dock is showing the saved image
>>>> will be used(and placed to the cache)
>>>>    * If the frame will be resized/show the cache will be reset.
>>>>    * When in the next time the same frame will be minimized the cached
>>>> image will be used.
>>>>
>>>> The bug is in the last step. When the frame will be minimized in the
>>>> second time, it can have another content. But minimized icon will show
>>>> the miniature from the previous minimization. Note this is the only
>>>> step where the cache is used.
>>>>
>>>> Solution:
>>>> As a solution all cache related stuff were dropped. The new test was
>>>> added.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144166
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8144166/webrev.01
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.



More information about the swing-dev mailing list