<AWT Dev> [8] Review request for 8016356: Any swing frame resizes ugly.

[Oleg Pekhovskiy]

Hi Anthony,

On 29.08.2013 17:16, Anthony Petrov wrote:
> Hi Oleg,
>
> On 08/28/13 01:35, Oleg Pekhovskiy wrote:
>> On 26.08.2013 17:20, Anthony Petrov wrote:
>>> The fix looks somewhat fragile to me. The sequence of events may change
>>> in a future version of Windows, and the fix will fail then.
>>
>> I agree, the fix is not elegant.
>> As for the future: I tested it on Windows 8.1 - it worked.
>
> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you
> can't test with Win 9 or Win 19 yet, can you? :)
>

Sure, no guarantee...

>
>>> Are there any peculiarities for the WM_SIZE messages being posted when a
>>> window is snapped? I'm referring to [1] for example, and they suggest
>>> that a proper SC_ flag might be specified when snapping occurs. So, if
>>> we could detect that, we might unblock the WindowResized() call at the
>>> end of the WmSize() method in the AwtWindow class, which would fix the
>>> issue.
>>
>> Unfortunately there is not direct way to determine the snapping.
>> My experience says not to play with sending system events manually on
>> Windows. That is much more fragile and nobody knows how DefWindowProc()
>> would behave.
>
> I totally agree.
>
>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's
>> synchronous during window resize (looping in AwtWindow::DefWindowProc())
>> So WindowResized() would be called only when the user releases mouse
>> button after resizing. But WM_SIZE message is called each time the size
>> of the window is changed while resizing.
>
> Aren't the position/size of a window change noticeably greater from one
> WM_SIZE message to the next one when the snapping occurs, as opposed to
> normal resizing? Could we introduce a threshold and only call
> WindowResized from WmSize() if the size/position change is greater than
> the threshold?

Unfortunately, that's impossible in, at least, to cases:
1. The height of window is near the height of desktop, so snapping 
increases the height of window just for a few pixels.
2. The mouse is moved quite fast during the simple resizing (I got >100 
pixel increase for one WM_SIZE message).

>
> I realize that such a solution is no more elegant than your original
> one, but at least it doesn't rely on a particular sequence of different
> messages, which may change in future versions of Windows.
>
> --
> best regards,
> Anthony
>
>>
>> You might also want to explore the WM_WINDOWPOSCHANGED and
>>> WM_WINDOWPOSCHANGING events that the window receives during snapping,
>>> perhaps they have some characteristics allowing us to ignore the
>>> IsResizing() and call the WindowResized() nonetheless.
>>
>> These messages are sent "as a result of a call to the SetWindowPos
>> function or another window-management function" and never appears during
>> window resizing with the mouse.
>>
>>>
>>> [1]
>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc
>>>
>>>
>>>
>>
>> This article is an attempt to handle maximize/restore snapping, but this
>> issue deals with vertical snapping, when top or bottom edge of the
>> window moved to the corresponding edge of the screen.
>>
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote:
>>>> Hi all,
>>>>
>>>> please review the fix
>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/
>>>> for
>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356
>>>>
>>>> Windows 7 has a feature that makes "window being automatically arranged
>>>> when moved to the edge of the screen". And there is no specific system
>>>> notification when that happens. From the other side AwtWindow class has
>>>> some optimization algorithm for resizing that doesn't take into account
>>>> such the arranging. I found indirect way to determine the arranging by
>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the end of
>>>> resizing routine, and call WindowResized() when needed to update the
>>>> layout.
>>>>
>>>> Thanks,
>>>> Oleg