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

[Oleg Pekhovskiy]

Hi Artem, Anthony,

thank you for the review...

I've added more details in the source code comments and bug comments, 
plus changed "else" location.

Please review the next version of fix:
http://cr.openjdk.java.net/~bagiras/8016356.3/

Thanks,
Oleg

On 07.10.2013 16:02, Artem Ananiev wrote:
> Hi, Oleg,
>
> could you provide information (here and in bug comments), what are the
> values returned by GetWindowRect() and getWindowPlacement(), while the
> window is being snapped and after it has been snapped, please?
>
> Thanks,
>
> Artem
>
> On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote:
>> Hi All,
>>
>> Please review the second version of fix
>> http://cr.openjdk.java.net/~bagiras/8016356.2/
>> for
>> http://bugs.sun.com/view_bug.do?bug_id=8016356
>>
>> I found quite robust way to determine Windows Snap-feature that relies
>> upon the difference between the real (GetWindowRect()) and the normal
>> placement of the window (GetWindowPlacement()).
>> When a window goes snapped the actual and normal rectangles are
>> different. In this case WindowResized() method is called to send
>> ComponentResized event and update window layout.
>>
>> This check was placed in the handler of WM_SYSCOMMAND message right
>> after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc().
>>
>> Thanks,
>> Oleg
>>
>>
>> On 01.09.2013 10:32, Oleg Pekhovskiy wrote:
>>> 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