On 06/22/2009 06:38 AM, Artem Ananiev wrote:
I'd be personally fine with another approach: don't traverse up all the
parents of the components and check if they all are valid as it's done
now. Instead, we can find the top-most valid container and perform the
mixing for all its children only.
Could you elaborate on this proposal?
1. Have an invalid flag and an invalidForHwMixing flag. A call to
invalidate() would set both up the hierarchy until a validate root is
reach, then only the invalid flag would be set up until the root
window. A call to validate would of course clear both. The clip
algorithm would consider this invalidForHwMixing flag instead of the
invalid flag.
HW/LW components mixing is considered to be completely transparent for
the developers. That's why I think we shouldn't introduce any new
(public) API to support it. And introducing a new flag would make our
code even harder to understand.
Whilst I agree that adding a new flag is a bad idea from the code
readability point of view, I want to mention that the flag must not be
public at all. If we choose to implement this solution, the flag might
be private/AWTAccessor-accessible.
2. Make it so that revalidate does not mark the ancestors of the
validate root invalid. I wonder if this is a sensible approach though.
This is roughly what is described in 6852592.
This solution seems to be compatible with how Swing developers used to
write their code: calling revalidate() after layout-related information
changes is a known requirement. So modifying the method as suggested in
the RFE description would make all existing Swing applications
mixing-friendly - should they ever embed a hw component. But if they do
not embed anything hw, their behavior and performance should not be
greatly affected.
3. Do not take the invalid flag into consideration for the Lw/Hw clip,
but defer and aggregate (coalesce) shape calculations requests. This
Well, actually watching the 'valid' flag is a kind of deferring
implemented right now. But obviously it needs a better trigger.
<top-level>.validate() works, but is not convenient. Hence the discussion.
--
best regards,
Anthony
