Request for review: 7130587 - [macosx] Scrolling and painting issues with late invocation of setText

[Anthony Petrov]

Ah, I missed that part that getTextComponent() actually returns our 
internal Swing text component, not the target. Thanks for clarifying that.

I'm fine with the fix then.

--
best regards,
Anthony

On 1/25/2012 4:55 PM, Sergey Bylokhov wrote:
> 25.01.2012 16:44, Anthony Petrov wrote:
>> Hi Sergey,
>>
>> I'd like to clarify the logic behind invalidating/validating parts of 
>> component hierarchies.
>>
>> src/macosx/classes/sun/lwawt/LWTextComponentPeer.java
>>>  177     protected final void revalidate() {
>>>  178         synchronized (getDelegateLock()) {
>>>  179             getTextComponent().invalidate();
>>>  180             getDelegate().validate();
>>>  181         }
>>>  182     }
>>
>> Here we're actually dealing with two different, unrelated component 
>> hierarchies:
>>
>> 1. The real, user's hierarchy: the text component belongs to it. We're 
>> calling invalidate() for this real, AWT component which results in 
>> invalidating the component and its ancestors. Do I understand 
>> correctly that user's code is responsible for validating their 
>> components back after each setText()/insert()/etc calls? Is this how a 
>> HW AWT hierarchy behaves (e.g. on Win and X11)?
> No, we invalidate internal delegate(JScrollPane) starting from its child 
> TextComponent(JTextArea).
>>
>> 2. Our internal, not visible to the user hierarchy: the delegate Swing 
>> component belongs to this hierarchy. We're only calling validate() for 
>> it assuming that it's been invalidated somewhere else already. Is this 
>> correct?
>> Before we did invalidate it explicitly with a call to 
>> getDelegate().invalidate() in sendTextEvent().
> For textfield nothing changed because getTextComponent() returns 
> delegate. For textarea we start invalidating from the child(JTextArea) 
> of our delegate(JScrollPane)
>> Would it make sense to add a call to getDelegate().invalidate() before 
>> calling its validate() in LWTextComponentPeer.revalidate() to make 
>> sure the validate() isn't a no-op?
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 1/25/2012 4:18 PM, Sergey Bylokhov wrote:
>>> Hi Everyone,
>>> We should invalidate text component, when its state changed and then 
>>> we should validate its container.
>>>
>>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587
>>> Webrev can be found 
>>> at:http://cr.openjdk.java.net/~serb/7130587/webrev.00/
>>>
> 
>