<Swing Dev> [PATCH] DefaultDesktopPane fix
Alexander Potochkin
Alexander.Potochkin at Sun.COM
Thu Feb 26 14:36:43 UTC 2009
Hello Roman
> Hi Alexander,
>
>>> 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,
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?
any other tests are also welcome
It is always better to have a clear test case before fixing a problem
>
> This means we cannot rely on copyArea to copy pixels that are obscured
> by some other window, even if it works (more or less by good luck) on
> some system. And I think we do something similar already in JViewport.
> So it only makes sense to do it here too, no?
Thanks
alexp
>
> /Roman
>
More information about the swing-dev
mailing list