<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