<Swing Dev> How to resolve image tearing

[Anthony Petrov]

On 5/27/2011 7:33 PM, tom.hawtin at oracle.com wrote:
> On 27/05/2011 15:37, Walter Laan wrote:
>>> We didn't change JComponent.repaint() to make it "no longer thread
>> safe"
>>> and I don't see why someone may think about it
>>
>> The bug report https://netbeans.org/bugzilla/show_bug.cgi?id=192548
>> shows the stack:
>> -
>> With the latest changes to jdk7 and jdk6 update 22 it's no longer true
>> due to
>> repaint()'s call to getLocationOnScreen() which acquires AWT tree lock:
> 
> Whilst not ideal, it doesn't seem unreasonable that repaint should 
> acquire a lock (that's usually how thread-safety is done).
> 
> The stack trace in that bug doesn't appear to show a deadlock as such. 
> What it does show is Netbean waiting on one of its own locks on the AWT 
> EDT.
> 
> "AWT-EventQueue-0" prio=6 tid=0x04713c00 nid=0x7d8 in Object.wait() 
> [0x0599e000]
> 
>    java.lang.Thread.State: WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x1c24efb0> (a 
> org.netbeans.lib.editor.util.PriorityMutex)

Thanks Tom. That's a nice find.

I'm not sure if this is documented somewhere (if not, it should be), but 
while being multi-threaded, AWT doesn't tolerate blocking of the EDT 
under any circumstances. It's a general understanding/agreement that 
events must be processed as fast as possible. Moreover, this is 
especially relevant to Swing since most of Swing operations should take 
place on the EDT *only*, and as such keeping the thread unblocked is 
vital for Swing to operate correctly. The library even provides the 
SwingWorker utility class that helps process long operations while 
allowing the EDT to handle other events.

The only allowed case when the EDT can be blocked is displaying a modal 
(J)Dialog by means of calling its setVisible(true) from an event 
handler. In this case AWT/Swing are responsible for keeping the wheel 
rolling. In all other cases a blocked EDT may cause problems that 
AWT/Swing simply can't resolve.

So, if the deadlock (or whatever it is) is caused by blocking the EDT, 
this suggests that it is NetBeans that's causing the problem, not JDK.

--
best regards,
Anthony