<Swing Dev> How to resolve image tearing

[ximalaya]

Thank you all, good conclusion to JDK users, :)

At 2011-05-28 01:40:28，"Anthony Petrov" <anthony.petrov at oracle.com> wrote:

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20110531/b65be680/attachment.html>