<Swing Dev> How to resolve image tearing

[Alexander Potochkin]

Hello Ximalaya
> Thank you all, good conclusion to JDK users, :)

A small follow-up from me:

JComponent.repaint() indeed called getLocationOnScreen() for a short 
period of time in JDK 7
but it was fixed in b132, the bug's number is 6993171

JDK 6 has never have it

Let me know if there are any problem with that

Thanks
alexp

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