bugGNUstep - Bugs: bug #22261, Window turns black during resizing...


bug #22261: Window turns black during resizing on Win32/MINGW when GSBackHandlesWindowDecorations==TRUE

Submitted by:  Chris Armstrong <carmstrong>
Submitted on:  Sat 09 Feb 2008 01:23:03 AM UTC  
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  Fred Kiefer <FredKiefer>
Open/Closed:  Closed

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Thu 14 Feb 2008 11:19:10 PM UTC, comment #5: 

I commited your patch and also cleaned up the window backend code. Now it is at least basically maintainable.

The same open issues remain. I am still not convinced that your fix is the best way to address the resize problem. But the search for the best solution can wait now.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Tue 12 Feb 2008 12:44:03 AM UTC, comment #4: 

I don't know if this would help, but we could try and define window server events with a greater granularity, and start to remove some of the assumptions the frontend makes about the backend (such as disabling drawing during a resize). Quickly looking through the code in NSWindow, it appears that the gui frontend attempts to handle some things itself or infer what has happened in response to certain events due to deficiencies in the X server or window manager.

Chris Armstrong <carmstrong>
Mon 11 Feb 2008 11:59:26 PM UTC, comment #3: 

The redrawing while resizing problems on X11 are just the same as on Windows. You sometimes get a black window when the application is to busy to do a redraw while resizing.

What happens when a window gets resized is that the backend will be notified from the window system about the new size. It then sends an GSAppKitWindowResized event to the front end (which only happans in some cases for Windows) and NSWindow _processResizeEvent calls setWindowdevice:forContext:, which takes over the actual resizing and the adjusting of the drawing environment. It may well be that this method also should do a needsDisplay:, but I am not sure.
The setWindowdevice:forContext: method is the place where I would expect resizeBackingStoreFor: to be called, but currently this is different for the windows backend (Why?).
Now all this strange behaviour was there before your patch, but perhaps your patch could look different with it being resolved.

The other part is where and how we want redraws to happen. In GNUstep (almost) all redraws should come from the _handleAutodisplay method on NSWindow. This does a displayIfNeeded followed by a flushWindowIfNeeded. This is a drawing mechanism that does not go via the standard Windows WM_PAINT route. WM_PAINT should only apply when a part of a window gets exposed by window movement or resizing. Your mechanism to deal with that case may be the correct one, I am just not sure, it doesn't have any side effects for the other cases. Maybe I just need to look at the code a bit longer.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Mon 11 Feb 2008 10:31:30 PM UTC, comment #2: 

Well if its not the correct solution, I'd be willing to clean it up. Could you provide me with more information about the current problems with resizing and redrawing that exist e.g.
 - open bugs on Windows and X11
 - methods and functions in the gui frontend (such as NSWindow and NSApplication classes).

You also mentioned cleaning up the Windows backend. What do you think a "clean" windows backend will look like? Do you just mean removing the stub code, fixing typos and documentation, etc.? A list of things to do would be helpful. I will file any further changes to the backend as bugs.

However, if the patch is acceptable as it is, could you please apply it so that others can benefit from it? Once applied, redrawing during resizing works just like any other Windows application. All I have really done is implement the WM_PAINT event handler just as per the Windows documentation. Whilst Windows provides a rich interface for painting and sizing, moving and activating/deactivating windows, we should try and behave as much like a Windows application as possible. For example, the backend behaves subtly differently when we turn on native Windows window borders and taskbar usage.

Chris Armstrong <carmstrong>
Mon 11 Feb 2008 02:55:24 PM UTC, comment #1: 

This is a great patch and it is even more important that somebody takes up cleaning up our MS Windows code.

That said, I am not sure, whether this is the right answer to the general problem. All of our backends have, or or less redrawing problems while resizing the window.
For Windows this could be increased, as resizing is handled on the WM_SIZE and not WM_SIZING level, but I am not sure about that.

Perhaps we could come up with a general concept, when and where redrawing should be triggered during the resizing. There are some new methods on NSWindow that could help with that, again I am not that sure.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Sat 09 Feb 2008 01:23:03 AM UTC, original submission:  

On a MINGW target, the contents of a window turns black during resizing, staying black during the resize (even if you don't move the mouse). It restores the contents of the window after the resize.

This only occurs when the user default GSBackHandlesWindowDecorations is set to 'TRUE' or '1'.

gnustep-startup-0.19.0 (includes gnustep-back-0.13.0, gnustep-gui-0.13.0)
MINGW (MSYS 1.0.11)

1. Setup on a MINGW target
2. Set the user default GSBackHandlesWindowDecorations to true i.e.:
defaults write NSGlobalDomain GSBackHandlesWindowDecorations 1
3. Startup a GNUstep application (I have been testing with Gorm). The windows in the application should have native window decorations (not drawn by GNUstep).
4. Position the mouse cursor over a window edge and then click down the mouse button. The window should turn black.
5. Release the mouse button. The window will restore its contents.
6. Repeat step 4 & 5, but drag the mouse around to resize the window. The results should be the same.

Attached is a patch that corrects the problem. This patch operates by setting a flag whenever the backing store is flushed and needs redrawing.

Chris Armstrong <carmstrong>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #15005:  gnustep-back-0.13-blackwindows.patch added by carmstrong (3KiB - application/octet-stream - A patch against gnustep-back 0.13 that corrects the problem.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by carmstrong (Submitted the item)
  • -email is unavailable- added by carmstrong

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-02-14 FredKiefer StatusNone => Fixed
        Assigned toNone => FredKiefer
        Open/ClosedOpen => Closed
    2008-02-09 carmstrong Attached File- => Added gnustep-back-0.13-blackwindows.patch, #15005
        Carbon-Copy- => Added carmstrong

    Back to the top

    Powered by Savane 3.6