Hi Audrius, first of all, I didn't want to offend you. Sorry if you feel like this.
> >> * 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.
Ah ok then, I only looked at the patch and Changelog without noticing
that it's already reverted. It seems that there is one (irritating)
artifact left:
Component parent = component.getParent();
> >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.
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.
> To remove this, we must somehow make the
> blitting
> work also if the JViewport is not the painting root.
Lets discuss this separately. Though I'm curious in which way the
blitting was broken.
> >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).
I think I explained that. Painting with overlapping components is
broken, and painting components that are not adjecent is slower (because
they get their dirty rectangles merged in the parent, which possibly
includes area which is not dirty at all).
> 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.
Sure it is. I am currently working on a fix for this.
> 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.
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.
> >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.
Oh please, I didn't want to offend you or anybody working on Swing. I
also didn't say that I wrote a majority of it or anything. But its
arguably true that I worked several days/weeks on the RepaintManager and
JComponent painting code, and have already fixed the problems that now
reappear a long time ago.
> 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,
Man, cool down. This is stupid. I don't want no competition either, and
getting higher up in the hierarchy? Duh, all I want is to hack and have
fun and produce quality code.
> After my change, you have subsequently applied the two pathes, each of
> them introducing new Swing regressions (broken button panel and broken
> table blitting).
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.
/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
