<Swing Dev> How to resolve image tearing

[Pavel Porvatov]

Hi all,
>
> On 5/26/2011 10:16 PM, ximalaya wrote:
>> Hi Anthony,
>> Thanks for your replies in last month. I still still have some questions
>> and need your help.
>>
>> 1. Method paint of Canvas(hw component) is not called when its container
>> JPanel repaints
>> I have a JFrame. Inside the JFrame, there is a JPanel. And inside the
>> JPanel there is a Canvas. I found Canvas.paint was never called when I
>> call JPanel.repaint(). Is it normal? Is it just another case we simply
>> can't sync up with repainting of lw and hw components?
>>
>> 2. Thread safe of Componet.repaint//JComponent.repaint()/
>> I ever read some articles about JComponet.repaint. It was said that it
>> was thread safe. But I learn from an article that JComponet.repaint is
>> no longer thread safe since JDK 6 update 22 -
>> "/do not call JComponent.repaint() outside the Swing Event Dispatch
>> Thread" ,
>> / You can find the article here, 
>> http://stevensrmiller.com/wordpress/?p=567
>
> It's the first time I've heard about it. Looks like a terrible Swing 
> bug, doesn't it? Unfortunately, there is no information about why 
> exactly repaint() is no longer thread-safe, so I'm very skeptic about 
> this post. Let other Swing team members comment.
I believe the described problem (see 
https://netbeans.org/bugzilla/show_bug.cgi?id=192548) relative to bug 
6993171 and was fixed in jdk7b132.

Regards, Pavel
>
> Thanks,
>
> Artem
>
>> Does it apply to Componet.repaint also?
>>
>> Thanks and Best Regards,
>> Xmly
>> On 4/18/2011 8:51 PM, ximalaya wrote:
>> > Sorry, I don't quite understand why we simply can't sync up with
>> > repainting of lw and hw components. Could you please give me more
>> > information?
>>
>> We can't determine when a third-party hw component repaints itself.
>> Therefore we can't simply paint non-opaque lw components onto the
>> surface of the hw component.
>>
>> The only way to implement mixing for non-opaque lw components, as we see
>> it currently, is to turn them into hw components and recalculate their
>> shapes each time the lw components paints anything onto itself.
>> Alternatively, we could leave lw component being lw, and instead
>> calculate the shape of a "ho! le" to cut off of underneath components.
>> Either way, the performance of such solutions leaves much to be desired
>> because lw components may repaint themselves very frequently.
>>
>> Note that currently mixing is implemented by cutting off hw components
>> based on shapes of lw components (i.e. the second option above). And
>> since we support opaque lw components only, their shape is always
>> rectangular, which doesn't hurt the performance of the hw/lw mixing 
>> feature.
>>
>> In your case, you update the content of your own hw canvas yourself.
>> Hence, as a final step you can simply paint your text for each frame of
>> your graphics right onto the canvas, and (baring the vertical sync
>> issues) this should provide reliable results.
>>
>>
>> > For the difference between openJDK 1.6.0_18 and latest openJDK, please
>> > pay attention that, openJDK was used in our test. I am not sure the 
>> code
>> > base of openJDK 1.6.0_18 is same as JDK 1.6.0 u18, per! haps you 
>> can have
>> > a try with openJDK?
>>
>> I'm still unable to identify any change that could break the hw/lw
>> mixing in 6u18. Could you please provide more details of what exact
>> issue you're experiencing? A small test application that demonstrates
>> the issue would be very helpful. Thanks.
>>
>>
>>