Created attachment 31393 [details]
screenshot

Hmm, mixing with heavyweight components will always be a problem in Swing, I'm
not sure if we can do anything here...

This mixing seems to be a common problem for all docking frameworks. I found
this particular workaround based on Container.setComponentZOrder().
I've read somewhere that the JOGL team came up with something regarding
heavyweight/lightweight mixing.

Sorry, the link I found:

http://www.vlsolutions.com/en/documentation/docking/tutorial/tutorial7.php

I have been evaluating Rich's prototype and had also ask David about the
painting issues.

Java3D and JOGL both have HW AWT Canvas specializations, like the JDIC browser
component does.  JOGL does also have a Swing component.  I talked to the Sun
engineer who worked on it.  He said that they worked around the HW mixing
problem by rendering the to an offscreen buffer and then copying to JOGL Swing
component.  This of course has performance issues and the engineer suggested
that, naturally, as the dimenions of the JOGL Swing component increases the
performance falls off wrt to fps.  For Mustang, as part of some Java2D
performance improvement work they have come up with a special optimization for
the JOGL Swing component which minimizes or eliminates the copying.  The result
is that the JOGL Swing component will perform better in Mustang.

Its obvious to me that duplicating the JOGL Swing component design for the JDIC
browser is interesting idea.  However, given the predictably large size of the
component the buffer copying technique would not be a success.  I can't recall
exact reason but the JOGL optimization technique would also not be possible.

Specifically on this issue I am attaching four (4) screen shots.

BrowserBaseLine shows the JDIC Browser TC working good when first started.  I
get scrollbars (from IE) for the large HTML pages and the TC fits in well with
NB Windows.  If I resize NetBeans (Shrink) I do NOT get proper resizing of the
browser and it paints beyond its window boundary and is only clipped by the HW
frame. (See BrowserResize1)

From the baseline (notice properties window at SW corner) if I dock Properties
Window into the margin it causes a slight horizontal reduction of the browser
TC...(see BrowserResizeAfterDockingProperties) and the Browser again is not
resized propertly and overlaps on the right.

This strikes me as a resize problem; one which could be overcome by coordinating
events from the NB Window system pushed down on the TC to the JDIC component.

I believe that Rich's original issue description and screenshot is
representative of a resize problem that results in overlapping the Output. 
Whether this resize problem is in the JDIC or in the TC encapsulation I don't
know but I would be aghast if the JDIC component couldn't handle resizes after
all these years.

There is still, as I showed David in person in Prague this week, as classic
Z-order problem when you try to "float" the docked Properties Window.  In this
case we are intentionally overlapping.  David suggested (and I agree) that this
is unfixable given the general matter in Swing with LW HW mixing.  He did
believe that a suitable workaround may be fine.  Conceptually, we could
temporaily disengage Window System floating feature WHILE a HW TC isShowing.  I
don't know much about UI useability but perhaps the FLOAT behavior can be
replaced with "restore" WHILE a HW TC isShowing.  Essentially, one can minimize
a window and then restore...but not float WHILE a HW TC isShowing.

Comments?

Created attachment 31992 [details]
BaseLine

Created attachment 31993 [details]
Resize NB Smaller

Created attachment 31995 [details]
docking "minimizing" Properties Window

Created attachment 31996 [details]
Float Properties Window (Z-ordering issue)

Are you suggesting that I should add a ComponentListener on the browser's
TopComponent and do:

void componentResized(...) { jdicWebBrowser.setBounds(...); }

I'm trying to mitigate some of these issues (except for the "floating dock" problem) by adding the following to my TC
definition:

        addComponentListener(new ComponentAdapter() {
            @Override
            public void componentResized(ComponentEvent evt) {
                if (evt.getID() == ComponentEvent.COMPONENT_RESIZED) {
                    Rectangle bounds = evt.getComponent().getBounds();
                    m_browser.setBounds(bounds.x, bounds.y, bounds.width, bounds.height);
                    System.err.println("NEW BOUNDS: " + bounds.x + ',' + bounds.y + ',' + bounds.width + ',' +
bounds.height);
                }
            }
        });

...however, I am not getting new events when docking new components in neighboring modes (like Properties), or resizing
docked components.  Should I be listening for something else?

Docking frameworks such as Jide (www.jidesoft.com), and VL Docking (www.vlsolutions.com) solve this problem by using a
heavyweight container whenever a tab partially overlaps another tab.  

That is, when you minimize TopComponent 'A' to the side, and press the button to show A again, it is displayed on top of
the existing components.  If any of those is a heavyweight, say B, (and A isn't a heavyweight), B will be painted on top
of A despite it should have been the other way around.  

The solution is to make sure that whenever a TopComponent (including decorations such as x-button) is displayed on top
of the others, it is put in a heavyweight container (e.g. java.awt.Panel) before adding it to the Swing tree.  Using
this simple trick, all paint order problems are gone!

passing to saubrecht - we really should try to fix this soon, see last comment from willemv, it shouldn't be hard. For
original problem with browser, I don't know why resizing events are not coming? More evaluation is needed.

i've tried jdk 1.6.0_12 and popup menus and sliding windows are painted correctly above heavyweight components (i tested
java.awt.Canvas)

closing