<AWT Dev> RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

[Sergey Bylokhov]

On 4/8/20 5:14 pm, Philip Race wrote:
> 
> 
> I was trying to make it flow better and avoid some repetition
> I did not think it necessary to enumerate subclasses> What motivates you to include "behavior"  ?

To cover cases like animation during maximization/minimization of windows,
or animations when the window appeared on the screen.

> Visual effects such as halos, shadows, motion effects and animations may
> be applied to the window by the desktop window management system.
> These are outside the knowledge and control of the AWT and so for the
> purposes of this specification are not considered part of the AWT-defined window.

I have never seen "AWT-defined window" term, I assume we never used it before is it
clear enough? Usually, we use "Top level window" which will cover AWT and Swing.


> 
> -phil.
> 
> On 4/8/20, 5:03 PM, Sergey Bylokhov wrote:
>> On 4/6/20 12:24 pm, Philip Race wrote:
>>> If we have to add anything I prefer the following :
>>>
>>> Visual effects such as halos, shadows, motion effects and animations may
>>> be added by the desktop and affect the actual or perceived position, dimensions
>>> or shape of the window.
>>> These are usually outside the knowledge and control of the JDK and so for the
>>> purposes of this specification are not considered part of the AWT-specified window.
>>
>> Are this text more clear than my version? I create it using the text forms/terms which
>> are already present in the javadoc.
>>
>> The text where we describe bounds/location optionality:
>>  126  * Note: the location and size of top-level windows (including
>>  127  * {@code Window}s, {@code Frame}s, and {@code Dialog}s)
>>  128  * are under the control of the desktop's window management system.
>>  129  * Calls to {@code setLocation}, {@code setSize}, and
>>  130  * {@code setBounds} are requests (not directives) which are
>>  131  * forwarded to the window management system.  Every effort will be
>>  132  * made to honor such requests.  However, in some cases the window
>>  133  * management system may ignore such requests, or modify the requested
>>  134  * geometry in order to place and size the {@code Window} in a way
>>  135  * that more closely matches the desktop settings.
>>
>> The new text about visual perception:
>>  137  * The visual appearance and behavior of top-level windows (including
>>  138  * normal/shaped/translucent/undecorated {@code Window}s, {@code Frame}s,
>>  139  * {@code Dialog}s) are under the control of the desktop's window management
>>  140  * system. The visual effects as shadows, motion effects, animations,
>>  141  * and others may not be controlled by the applications but work according to
>>  142  * the desktop settings.
>>
>> Both look aligned.
>>


-- 
Best regards, Sergey.