Hello Anthony
So the code is ready to the situation when there is no validate root
If you make Window a validate root,
the for loop will always find it and the logic will be changed
Yes! And that seems to be completely correct: we HAVE TO call validate()
on a validate root (or a top-level component - whichever we find) - no
matter what is the component that represents the found validate root -
an old-good Swing RootPane, or the top-level window. So, whichever we
find - we just schedule the invocation of the validate() method on that
component, and therefore make the hw/lw mixing-related code happy. :)
Ok
This is something to keep in mind
So I think the current code (including the rewritten version as you
suggest) perfectly fits to the idea of making top-level windows validate
roots.
That said, the invalidate() method may easily jump to the owner of a
dialog (or a window) while invalidating the hierarchy of the owned
window - which is absolutely incorrect. To make sure this never
happens, we need to stop invalidating on top-level components, hence
the need to make the Window a validate root.
Sounds reasonable?
Yep
Great! And thanks for reviewing the code! By the way, are you proposing
to apply the suggested chunk of code to the RepaintManager with this
fix, or is it going to be a separate CR?
I tend to not file extra CR's,
could you please take care of it with this fix?
RM.addInvalidComponent() and JViewport.validateView()
are only methods to be updated
Thanks!
alexp
--
best regards,
Anthony