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

[Sergey Bylokhov]

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


-- 
Best regards, Sergey.