Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails

Anthony Petrov anthony.petrov at oracle.com
Thu Feb 2 06:38:48 PST 2012


Thanks for filing the RFE. I'm OK with the current fix then.

--
best regards,
Anthony

On 02/02/12 17:34, Sergey Bylokhov wrote:
> Done:
> http://monaco.us.oracle.com/detail.jsf?cr=7142091
>
> 02.02.2012 16:37, Anthony Petrov wrote:
>> On 02/02/12 15:56, Sergey Bylokhov wrote:
>>> 01.02.2012 23:00, Anthony Petrov wrote:
>>>> On 2/1/2012 9:06 PM, Sergey Bylokhov wrote:
>>>>> 01.02.2012 20:22, Anthony Petrov пишет:
>>>>>> All the other peers call super.initialize() in the beginning of
>>>>>> their overridden initialize() methods, and making an exception just
>>>>>> for the LWWindowPeer seems to be inconsistent.
>>>>> Well, I believe that all other components should call
>>>>> super.initialize() at the end too. I just have no time to test them
>>>>> all. Because it is cause lots of unnecessary repaints. We shouldn't
>>>>> initialize components after we show them.
>>>>
>>>> I agree, partially. I believe that the setVisible() call should indeed
>>>> follow all other initialization. However, the rest of settings which
>>>> LWComponentPeer.initialize() performs should go ahead of custom
>>>> initialization performed by specialized peers, because custom
>>>> initializers may in theory tweak the general settings.
>>> Well, if custom initializer want to tweak the general settings, it
>>> should tweak it not just during initialization but during regular
>>> changes too? For example if sub class want to tweak its bounds it should
>>> do it in setBounds not in initialization. I'll create separate RFE for
>>> refactoring of peer initialization.
>>
>> Thanks.
>>
>> --
>> best regards,
>> Anthony
>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>>> Since the only reason for that is to postpone the setVisible() call,
>>>>>> I would suggest either introducing pre- and post-Initialize()
>>>>>> methods (the approach is similar to XToolkit), or there might be a
>>>>>> flag that could be reset in LWWindowPeer ctor that would indicate
>>>>>> that LWComponentPeer.initialize() shouldn't call setVisible(). Then,
>>>>>> the LWWindowPeer.initialize() would call setVisible() as its last
>>>>>> step.
>>>>>>
>>>>>> It just seems that having the inconsistency as present in your
>>>>>> current fix may hurt us in the future when e.g. we modify the logic
>>>>>> in the LWComponentPeer.initialize() and would expect it to be in
>>>>>> effect before setting additional properties for the LWWindowPeer.
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote:
>>>>>>> Hi Everyone,
>>>>>>> Peers shouldn't accumulate an alpha after repainting, so clearRect
>>>>>>> was added. And now we call setVisible for window after full
>>>>>>> initialization.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367
>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>


More information about the macosx-port-dev mailing list