Roman Kennke wrote:
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.
This is not ok. Some easy tests with Sun's implementation shows ...
This code is now overridden by the subsequent change, as adding the
highest possible root was breaking the blitting. I do not know if this
discussion is applicable for the recent code version. (addDirtyRegion)
currently works as before.
2006-05-15 Audrius Meskauskas <[EMAIL PROTECTED]>
* javax/swing/JComponent.java (findOverlapParent): Stop loop at
JViewport's.
This is also wrong.
This was necessary to make the blitting work, as as it only works when
the JViewport is
the painting root. This change is not related to my changes in the
RepaintManager and
should be discussed separately. To remove this, we must somehow make the
blitting
work also if the JViewport is not the painting root. Probably the parent
should not
blank the background if it is completely covered by the child.
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)?
Sorry, but this seems the plain FUD for me. Would you be so kind as to
say what exactly in the Swing demo or some other application is broken
and what exactly is slower (I would work on fixing then). What about a
nice bug report? If you say "general case", it should be numerous
examples. From the other side, I have an impression that repainting the
same component nine time in a row can surely be called both broken and slow.
The idea of asking the parent to repaint the multiple dirty regions and
not the single merged rectangle is good, but this does no require to
revert the current patch. The recangles - union should be replaced by
the collection of the individual rectangles.
This can be easily done, but we need to think a little bit before
programming this. The regions still should probably be merged if they
overlap, otherwise we will come back to the redundant repainting.
However this also may slow the user components that does not handle the
repaint boundaries, repainting the whole rectangle instead. Such
components will just do redundant repaints of the whole region. Also,
some user algorithms may not be able to repaint the part of the region -
just all or none. Others may be more effective when repainting the large
area at once rather than the same area, composed from the multiple
pieces. But if somebody else in the community will confirm this is a
good idea, I will implement this - easy to do.
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.
You are not the only person who is working on Swing here, and the
absolute majority of it (over 80 %, if I understand correctly from the
StatCVS) is not written by you. Please respect others as well. Swing is
in the very active development now. The internal competition between the
developers will bring us no benefit. You cannot get into the higher
level of the hierarchy here, because, unlike some well known other
projects, GNU Classpath has no hierarchy in general. This is why I like
this team.
After my change, you have subsequently applied the two pathes, each of
them introducing new Swing regressions (broken button panel and broken
table blitting). The button panel was subsequently fixed, but the code
is not the same. The table blitting remains broken. If anybody in the
team is going to test the effects of the RepaintManager change, they
should return to the CVS version of the 2006-05-15 inclusive.
Audrius.
