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

Reply via email to