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.
