<AWT Dev> [8] Review Request: JDK-8024864 [macosx] Problems with rendering of controls

[Sergey Bylokhov]

Hi, Petr.
The fix looks good.

On 10.10.2013 17:50, Petr Pchelko wrote:
> Hello, Sergey.
>
> I've updated the fix according to your comments:
> http://cr.openjdk.java.net/~pchelko/8024864/webrev.01/
>
> With best regards. Petr.
>
> On 10.10.2013, at 14:34, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>>
>> 315         Rectangle newBounds = new Rectangle(getBounds());
>>
>> It is not necessary to create new Rectangle, because getBounds creates it too.
>>
>> typo:
>>
>> 324so the peer wold be updated in the callback
>>
>>
>> On 10.10.2013 11:56, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8024864
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>>>
>>> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds.
>>> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.