[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-swing-dev
Subject:    <Swing Dev> How to resolve image tearing
From:       Alexander.Potochkin () oracle ! com (Alexander Potochkin)
Date:       2011-06-02 17:35:08
Message-ID: 4DE7C9CC.7030009 () oracle ! com
[Download RAW message or body]

Hello Ximalaya
> Hello Alexander,
> Thanks for your information! Then users who are using JDK7 prior to 
> b132 need to take care of it.
>
> BTW, some questions on JDK/OpenJDK releases.
> 1. from the bug URL
> http://hg.openjdk.java.net/jdk7/swing/jdk/rev/493a9eeb9bca
> Does it mean openJDK7 and JDK7 are sharing same code base now? or when 
> you mention JDK7, you mean openJDK7 actually?

this is the fix I mentioned, if you have it there should be no problem
openJDK7 does share the code base with JDK7

>
> 2. There is a genealogy diagram here, from the diagram, we can see 
> three trains, JDK6 update, OpenJDK 7(JDK7 published as OpenJDK7, this 
> might answer the question above), and OpenJDK 6, evolve continuously.
> http://openjdk.java.net/projects/jdk6/
>
> Can I say, there is actually no relationship between JDK/OpenJDK 
> update/build numbers, since they evolve in different trains? For 
> example, JDK6 1.6.0_18 has nothing to do with OpenJDK 1.6.0_18?

openJDK6 is a different story, it doesn't automatically share the code 
base with JDK 6,
so OpenJDK 1.6.0_18 may lack some fixes from JDK6 1.6.0_18
but the OpenJDK6 team is certainly working on them

>
> 3. Any feature level differences between Oracle JDK and OpenJDK? Which 
> one is recommended for commercial deployment? Must I release my 
> component under GPL if we use some JNI codes under OpenJDK?
> (Please help to forward to appropriate mailing list if necessary, 
> thank you.)

I am not an official JDK consultant so I can't say what JDK you should use,
please make your mind yourself
:-)

Thanks
alexp

>
> Thanks and Best Regards,
> xmly
> At 2011-05-31 21:39:09??"Alexander Potochkin" 
> <Alexander.Potochkin at oracle.com> wrote: >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 >> >> >
>


[prev in list] [next in list] [prev in thread] [next in thread]