Hi Audrius, I finally find some time to look into your optimizations. Unfortunately I don't think they are correct at all. (This is why I come to this at all - painting seems broken in some special cases, like when you have a textfield and open a menu that overlaps the textfield, the menu gets damaged by the textfield painting.)
Let me add some comments below.
> 2006-05-15 Audrius Meskauskas <[EMAIL PROTECTED]>
>
> * javax/swing/RepaintManager.java (addDirtyRegion):
> If there is a lightweight parent, recursively add the corresponding
> region of the parent instead.
+ Component parent = component.getParent();
+ if (parent instanceof JComponent)
+ {
+ // If there is a delegateable parent, add the parent region
instead.
+ addDirtyRegion((JComponent) parent, x + component.getX(),
+ y + component.getY(), w, h);
+ return;
+ }
This is not ok. Some easy tests with Sun's implementation shows that
this is not what addDirtyRegion() should do. We had it like this at the
beginning of my work on Free Swing and it proved to wrong in several
situations. Imagine you have one big component (I have seen this example
in the real world), with one small component (a clock) in one edge, and
a couple of other components. The small component gets updated
frequently. Now what happens when the clock and some other (far away)
component get updated at the same time? Two small rectangles get
union()'ed together and we get one big dirty region. This is not what we
want.
My implementation did the 'merging' part of parent-child components
differently: it sorts the dirty regions by their size (alternativly, we
could think about sorting it by their level in the component hierarchy),
and paint the bigger (or upper-level) components first. This way, we
always paint the parents before their children. Now, if a parent paints
a complete(!) child component, it marks the corresponding child
component clean and the RepaintManager should skip it. (Thinking about
it, it might be possible that the skipping part might not have worked
correctly, given that we work on a copy of dirtyRegions and the
markComponentClean operates on the other copy - maybe we should fix this
instead).
2006-05-15 Audrius Meskauskas <[EMAIL PROTECTED]>
* javax/swing/JComponent.java (findOverlapParent): Stop loop at
JViewport's.
This is also wrong. We always must go up to the toplevel component in
order to check if there is an overlapping parent. The menu/textfield
example is one case where this is very important.
Given that there are now a couple of issues (broken things, not only
slowness) with painting, may I suggest that we revert JComponent and
RepaintManager to the state we had before, and then we can look together
into the issues (maybe you log into IRC and we can discuss this in
realtime)? I literally have spent weeks on the implementation of the
painting stuff in Swing, I think I know the corner cases and pitfalls
pretty well. If you could describe the issues in detail, I promise I'll
fix these properly. As it is now, it might be faster for the
JInternalFrame handling, but slower in the general case, and broken in
some other cases.
Best regards, Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
