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

[Artem Ananiev]

Looks fine.

Thanks,

Artem

On 10/8/2013 9:14 PM, Oleg Pekhovskiy wrote:
> 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