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

Sergey Bylokhov sergey.bylokhov at oracle.com
Thu Feb 2 05:34:31 PST 2012


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/
>>>>>>
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.



More information about the macosx-port-dev mailing list