<AWT Dev> Lw/Hw mixing vs revalidate()/validate()/invalidate()
Artem.Ananiev at Sun.COM
Sun Jun 21 19:38:08 PDT 2009
thanks for raising this issue again. AWT and Swing teams had a numerous
disputes about (in)validation of lightweight/heavyweight components, and
the result is the RFE you're referring to: 6852592.
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.
See some more comments below.
Christopher Deckers wrote:
> Hi all,
> I was trying out the new Lw/Hw mixing capabilities and I found a big
> issue with it: for performance reasons, it does not calculate the
> shapes of native components when the hierarchy is not valid.
> The solution is not as simple as ensuring that the hierarchy is valid.
> Let me explain.
> I have a JFrame, with a JSplitPane, which contains a panel, to which I
> dynamically remove and add some content to basically change one side
> of the split pane. That panel may contain a native component. The way
> I do it is:
> The invalidation will bubble up to the window ancestor but the
> validation will only be done from the split pane, because it is a
> validate root. This means that if someNewContent has a native
> component in its hierarchy, its Lw/Hw clip will not be set.
> In this example, the hierarchy does not obey the contract to be valid,
> but it does not need to: nothing has changed in the parent hierarchy
> of the split pane (no layout to recompute), and nothing was added or
> For me, it is unclear whether the fix should be in AWT or Swing code.
> Originally after some discussions, we ended up with:
> but I am not convinced it is the right approach now.
> This issue is very important when integrating native components. A lot
> of applications have this type of behavior (like a selection in a tree
> shows various panels on the right side) and these dynamic additions do
> not necessarily know whether a native component is present (using
> component factories, 3rd party libraries, etc). This means the Lw/Hw
> mixing won't work in many Swing applications and developers will have
> a hard time understanding the reason.
> I can think of several fixes, though there may be other ways:
> 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.
> 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.
> 3. Do not take the invalid flag into consideration for the Lw/Hw clip,
> but defer and aggregate (coalesce) shape calculations requests. This
> may not seem as nice, but this is the approach I took in my native
> integration project  as I am outside the JRE.
This would be a fine approach for Swing code, but currently hw/lw mixing
is implemented at AWT side...
> Note that I CC the AWT list.
>  DJ Native Swing: http://djproject.sourceforge.net/ns/ - 0.9.9
> preview on SourceForge works with 6u14 by deactivating Sun's mixing.
More information about the awt-dev