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

[Anthony Petrov]

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)?

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(). 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/
>