Hi Alex,
> >>> I found a problem in DefaultDesktopPane. Dragging in fast mode does not
> >>> work correctly (at least not on all platforms) if the pane is obscured
> >>> by another heavyweight. Graphics.copyArea() isn't guaranteed to work
> >>> correctly in this case.
> >> This looks like a bug to me,
> >> could you please provide a small test case to illustrate this problem
> >> with Graphics.copyArea()?
> >
> > I don't know if it's actually reproducable with X11 or Windows (I think
> > it's reproducable with _some_ X implementation, just not with X.org).
> > But this behaviour is actually specified:
> >
> > <<If a portion of the source rectangle lies outside the bounds of the
> > component, or is obscured by another window or component, copyArea will
> > be unable to copy the associated pixels.>>
>
> I didn't know about that, thanks for the information
>
> The spec says that Graphics.copyArea() alway works this way,
Yeah, it sounds like this, but I don't think this is the case. My
interpretation is that this part of the spec accounts for limitations of
_some_ platforms and actually means 'we cannot guarantee that copyArea
works in such situations'. On platforms that draw windows directly on
the screen framebuffer, it is practically impossible (or at least
insanely complicated) to perform a copyArea on obscured parts of the
window. However, many modern windowing systems don't actually draw on
the screen framebuffer, but instead, each window has its own buffer and
all drawing is performed on that. Of course, when each window has its
own buffer, it's easy to perform a correct copyArea, even when the
window is obscured.
> just to be on the safe side could you please make a test
> to check is the problem can be reproducible with JInternalFrames
> on Windows or Linux?
>
> Something like dragging an internal frame
> under an "always-on-top" heavyweight?
Yeah, I did implement exactly that. However, it doesn't seem to be a
problem on my X server (Fedora 10 w/ or w/o compiz). I can reproduce the
problem on a DirectFB based graphics implementation though. A screenshot
is available here:
http://kennke.org/~roman/dragproblem.png
What you see there is two heavyweight frames (don't be confused by their
look: it's based on Caciocavallo and actually decorated by Swing - there
is no such thing as windows or decorations in DirectFB). One frame is
always-on-top of the other, and the 'lower' frame contains a
JInternalFrame. When I drag this internal frame to the left, it actually
copies whatever is on the framebuffer, in this case parts of the 'upper'
heavyweight frame.
Attached you find the testcase. Maybe you can reproduce it on Windows or
some other platform. But I hope that you will agree that with copyArea()
not guaranteed to work reliable in this situation we need to check if
the window is obscured and take action if it is (or if it cannot be
determined) - just like we do in JViewport.
> any other tests are also welcome
>
> It is always better to have a clear test case before fixing a problem
Sure. Let's hope you can reproduce the problem with the attached
testcase.
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt
import javax.swing.*;
public class TestDesktopManager {
public static void main(String[] args) {
JFrame f = new JFrame();
f.setBounds(50, 50, 600, 400);
f.setVisible(true);
JDesktopPane p = new JDesktopPane();
f.add(p);
JInternalFrame ifr = new JInternalFrame();
p.add(ifr);
ifr.setVisible(true);
ifr.setBounds(0, 0, 100, 100);
JFrame f2 = new JFrame();
f2.setBounds(100, 50, 600, 400);
f2.setAlwaysOnTop(true);
f2.setVisible(true);
}
}
