<Swing Dev> <AWT Dev> Lw/Hw mixing vs revalidate()/validate()/invalidate()

[Artem Ananiev]

Hi, Christopher,

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:
> panel.removeAll();
> panel.add(someNewContent);
> panel.revalidate();
> panel.repaint();
> 
> 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
> removed.
> 
> For me, it is unclear whether the fix should be in AWT or Swing code.
> Originally after some discussions, we ended up with:
> http://bugs.sun.com/view_bug.do?bug_id=6852592
> 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 [1] 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...

Thanks,

Artem

> Note that I CC the AWT list.
> 
> Cheers,
> -Christopher
> 
> [1] DJ Native Swing: http://djproject.sourceforge.net/ns/ - 0.9.9
> preview on SourceForge works with 6u14 by deactivating Sun's mixing.