This changes breaks the painting, as I explained, since it must be
scanned up to the root to determine if some other component overlaps the
component to be painted. If you try out a text editor (say, Notepad.jar
from Sun's demo programs), and open up a menu that overlaps the
JTextArea, the caret blinking repaint kills the menu.
This can also be reproduced with our Swing demo. However as I have
already posted in my previous message, the regression is caused by some
other change after May 14. The Classpath May 14 version with the recent
version of the RepaintManager has no this bug.
Lets discuss this separately. Though I'm curious in which way the
blitting was broken.
if (canBlit && isPaintRoot) in JViewport.paintBlit. Sorry, I thought
this is your code. But it is really not working is isPaintRoot is false,
I tried this.
I am currently working on a similar approach. However, I do not
generally merge the rectangles in the parent, I now do this only if
there is a dirty parent too. Then I merge the rectangles in there and
only repaint the parent. In the other case, when several components get
marked dirty, but none of their parents is dirty, the components get
painted separately.
Surely the RepaintManager can be rewritten again, we just need to check
if the ideas work.
Hmm, the broken button panel was the LightweightDispatcher fix, which I
think is correct now. What is table blitting and in which way is it
broken? Send me a note and I'll fix it.
The message, explaining this, was posted to the patch list in response
to your path "JTable fixes and improvements".
Audrius.
