• Sam Lantinga's avatar
    Date: Tue, 15 Feb 2005 21:28:48 +0900 (JST) · 31d40ce8
    Sam Lantinga authored
    From: "Michael Leonhard"
    Subject: [SDL] resize bug on Win32 and patch
    
    This is my first post to this mailing list.  In this email I will detail a
    bug in the behavior of resizable SDL windows on Win32.  Then I will
    explain the solution and provide a patch.
    
    Symptoms:
    
    Under Windows, an SDL display created with the SDL_RESIZABLE flag exhibits
    quirky behavior when being maximized.  The window is resized to the proper
    size, but it is shifted upwards about half the height of the title bar.
    Similarly, a window whose origin is above the top of the screen will
    spontaneously move its upper-left origin upon being resized.  After two
    such resize-induced moves, the title bar will be entirely off the top edge
    of the screen.  Subsequently, when the mouse is clicked and released on
    the window border, the window will shrink its height spontaneously.  This
    height shrinkage occurs even if the user did not resize the border.
    
    To observe this curious situation, please invoke:
    SDL-1.2.8/test/testwm.exe -resize
    
    Cause:
    
    A pair of integers, SDL_windowX and SDL_windowY, are defined in
    video/wincommon/SDL_sysevents.c.  They are used by the DirectX video
    driver and the DIB video driver:
    video/windx5/SDL_dx5video.c
    video/windib/SDL_dibvideo.c
    As I understand the source code, the primary use of these variables is to
    create a rectangle that represents the surface area in CLIENT SPACE.
    Client space refers to a coordinate system that originates at the upper
    left corner of a Win32 Window's drawable area.  This is just inside the
    window border and title bar.  This client space rectangle, called bounds,
    is subsequently converted to screen space with a call to
    AdjustWindowRectEx.  The problem is found in SDL's handling of the
    WM_WINDOWPOSCHANGED message.  According to MSDN,
    
      "The WM_WINDOWPOSCHANGED message is sent to a window whose
       size, position, or place in the Z order has changed as a
       result of a call to the SetWindowPos function or another
       window-management function."
    
    I have confirmed that this message is indeed being sent to the SDL window
    when the mouse is clicked on the window border, even if the window border
    is not dragged.
    
    In video/wincommon/SDL_sysevents.c, on line 464, in response to the
    WM_WINDOWPOSCHANGED message, the (potentially) new client rectangle is
    obtained.  This rectangle is translated into screen coordinates and THEN
    assigned to the SDL_windowX and Y variables.  Thus screen coordinates are
    being assigned to client coordinate variables.  Once this is understood,
    the solution is apparent:  assign SDL_windowX and Y before translating the
    rectangle to screen coordinates.  This is accomplished by the following
    patch.
    
    -Mike_L
    
    --HG--
    extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401290
    31d40ce8
Name
Last commit
Last update
..
audio Loading commit data...
cdrom Loading commit data...
cpuinfo Loading commit data...
endian Loading commit data...
events Loading commit data...
file Loading commit data...
hermes Loading commit data...
joystick Loading commit data...
loadso Loading commit data...
main Loading commit data...
thread Loading commit data...
timer Loading commit data...
video Loading commit data...
.cvsignore Loading commit data...
Makefile.am Loading commit data...
Makefile.wat Loading commit data...
SDL.c Loading commit data...
SDL_error.c Loading commit data...
SDL_error_c.h Loading commit data...
SDL_fatal.c Loading commit data...
SDL_fatal.h Loading commit data...
SDL_getenv.c Loading commit data...
SDL_loadso.c Loading commit data...