Why are the dimensions of a maximized window larger than the monitor?


When you inspect the window rectangle of a maximized window, you might notice that its dimension are actually slightly larger than the screen. The upper left corner is something like (−8, −8) and the lower right corner is correspondingly eight pixels beyond the bottom right corner of the screen. Why is that? /P>

The extra eight pixels that hang off the screen are the window borders. When you maximize a window, the window manager arranges things so that the client area of the window fills the width of your work area, and it plus the caption bar fills the height of the work area. After all, you want to see as much of your document as possible; there's no need to show you the window borders that aren't doing you any good. (It leaves the caption bar on the screen for obvious reasons.)

These extra pixels hanging off the edge of the screen don't normally cause any distress. At least, not until you have multiple monitors. And then they kind of annoy you, because they bleed over into the adjacent monitor.

Oh well.

Bonus chatter: When the taskbar was originally written, multiple monitor support did not yet exist in Windows, and the taskbar took advantage of this by simply letting its borders hang off screen, and when it went into auto-hide mode, it just moved itself off-screen save for a sliver of pixels. When multiple monitor support was added, those pixels bled over into adjacent monitors, and in the case of an auto-hide taskbar, you could see where the taskbar was hiding, because it merely slide onto the adjacent monitor. The taskbar fixed this by explicitly clipping itself to the target monitor.

Comments (23)
  1. Cesar says:

    Couldn't it also shrink the border size to 0 when maximized? Or would dynamically varying the border size from what's configured in the Control Panel cause compatibility issues?

    [Dynamically varying the border size would mess up apps which call Get­System­Metrics(SM_CX­FRAME) because the frame border would no longer match the system metric. -Raymond]
  2. NIck says:

    Raymond I don't see any window border bleed on my multi-monitor set up?

    [Ah, right. That problem has since been fixed thanks to the magic of DWM. The borders are still there. You just can't see them. -Raymond]
  3. SimonRev says:

    This post seems to describe how things worked a long time ago.  I remember noticing the extra pixels back in Win98 with multiple monitors.  At least as far back as XP this seems to have been fixed (possibly with clipping regions) — no border overhang onto adjacent monitors.

    The big thing that I notice is that the title bar reconfigures itself to be smaller when a window is maximized.  On Windows 8 you can notice that the centered and minimize/maximize/close buttons move down on the titlebar when it is maximized.

  4. SimonRev says:

    In fact, at least in XP it has to be messing with the clipping region of the window because when using the default theme windows got a slightly rounded region on the upper two corners, and the maximized version goes to rectangular.

    Just checked — even when using classic theme there is no overhang on XP.  I don't have any VMs for earlier versions than XP.

  5. Joshua says:

    The overhang is there on Windows 7 (DWM must be off to enable high contrast correctly before W8). I mitigated the problem by editing the border size (can't remember how but it saves in .theme files).

  6. George says:

    Thank you. I had vaguely wondered about the protrusion into the second monitor, but never got around to looking into it.

  7. 7-pixel-pedant says:

    Windows 10 seems to introduce something similar: transparent window borders!

    A (non-maximized) window sized to exactly fit the working area of the primary monitor (so the rectangle returned by GetWindowPlacement() equals the monitor working area) leaves transparent strips of 7 pixels each on the left, right and bottom of the window, where the desktop background is visible. Yet it's possible to perform window sizing actions with the mouse on these 7-pixel strips, that's why I'm referring to the phenomenon as "transparent window borders".

    A window arranged to cover half the primary monitor with Win+Left has no transparent strips around it, and the window rectangle is {left-7,top,(right/2)+7,bottom+7} relative to the monitor working area (simplified, but probably accurate enough for my example as the primary monitor origins at {0,0}).

    This breaks applications that perform their own checks to ensure they completely fit inside a monitor working area, as the coordinates for a (non-maximized) window completely covering the desktop start -7,0 earlier and exceed the previous end by +7,+7. Windows will move 7 pixels to the left when being closed and reopened, it's likely that SetWindowPlacement() will help here.

    But still, I must be missing something, does anybody see the logic behind the "transparent borders"? I feel things would be much simpler if the borders were completely omitted from window rectangle calculations.

  8. Guest says:

    @7-pixel-pedant

    Trying to grip on to a 1px thick border would get really tiresome after a while.

  9. 7-pixel-pedant says:

    @Guest: I agree, but I feel Windows should work with rectangles omitting the 7 pixel borders, and adding them "invisibly to the application" only if needed (mouse hovering, resizing), so that no window rectangle calculations are broken.

    One of my applications has a command line switch to open up with a non-maximized window covering half of the desktop (similar to pressing Win+Left), I don't know how to implement this on Windows 10 any more!

  10. dwm says:

    Funny, I just checked and I can see the border bleeding despite running Windows 8.1 with DWM (obviously). This is a dual-screen setup of a 1440×900 laptop screen + an external 2560×1440 display, and I see borders of applications maximized on the smaller screen bleeding to the larger one, but not the other way around. And it doesn't show for all applications; I see bleeding for Notepad, Explorer and Paint, but not for Firefox or Word 2010. Maybe it is because these are painting their own window chrome if maximized.

  11. Mike not signed in 'cause I can't read the CAPTCHA says:

    The Win 10 invisible borders are a trick.  The window rect is larger than the rect you get from DwmGetWindowAttribute(DWMWA_EXTENDED_FRAME_BOUNDS), which is backwards compared to previous versions.  The pixels that are in the window rect, but not in the extended frame bounds, are the resizing area.

  12. Cesar says:

    @IanBoyd: Don't forget that programs could draw into their icons. So an analog clock program could draw an analog clock as its icon, updating it every minute to the correct time.

    Minimized windows in the Windows 3.1 days were actually useful, unlike the taskbar from the Windows 95 days which is just a task switcher.

  13. Cesar says:

    @IanBoyd: BTW, nostalgia time: wow, it's been over 20 years. You could what you did by directly editing a simple text file. That was a simpler, more innocent time.

  14. gdalsnes says:

    "After all, you want to see as much of your document as possible"

    Yes, have to make sure to leave some space for those nice Ribbons.

  15. Deanna Earley says:

    @7-pixel-pedant Compatibility. Applications didn't expect their window borders to change or dissappear. Some apps resize content to $WindowSize – $MagicConstant. This breaks enough when they assume a window title size.

  16. Dave Bacher says:

    Evil Ribbons Stupid Ribbons.  NVM.

    Anyway — if the 7 pixel measurement is breaking positioning for your app — connect.microsoft.com is over there, file a bug.  Believe there's a uservoice for Windows 10 as well.  Anyway, report it to Microsoft — let them know now, while it's early, so they can fix it.  If you're having the problems, other apps probably are, too.

    Meanwhile — as a workaround, check the version, and set a magic constant to allow for the extra size.  And then just adjust as necessary right now. :)

  17. Torkell says:

    One program I run displays popups in a small window that it animates by sliding on and off the screen. This fails hilariously in a multi-monitor setup as the popup appears on one monitor, then slides across to the other one. Then it slides back to the first monitor before disappearing again.

  18. Azarien says:

    I remember seeing a bug with misplaced taskbar jumping up and down instead of auto-hiding.

    But I don't remember now what Windows version it was.

  19. IanBoyd says:

    In the olden days of Windows 3.1, we would edit Progman.ini so that the Program Manager window took up *most* of the screen. You set: Left=-4, Top=-4, Width=648, Height=420

    [Settings]

    Window=-4 -4 648 420

    The Left and Top of -4 was to account for the 4px window border. This way the left and top borders were off the left and top edges of the screen respectively. The window width then had to be 648 (640+4+4 on your 640×480 VGA monitor), so that the right-edge border of the Program Manager window was also off the right edge screen. This way the Program Manager window was nearly maximized, with no visible borders along the left, top or right.

    But we didn't extend Program Manager all the way to the bottom of the screen. We would intentionally leave a 40 or so pixel gap along the bottom of the screen. This let *iconized* applications still be visible along the bottom of the desktop. Before the taskbar you didn't "minimize" an application, you "iconified" it. It turned into a 32×32 icon along the bottom edge of the screen. If Program Manager were fully maximized, it would obscure those iconified running applications on the bottom of the screen.

    We were, essentially, inventing the Taskbar and we didn't even know it.

  20. 7-pixel-pedant says:

    @Mike, @Deanna Earley, @Dave Bacher: Thanks for the hints! I now understand the technical details behind the extra border, and I'm able to query it. Still, not sure how to fix the command line switch of my application to display as if Win+Left had been used, right at startup, as there seems to be no way to SET a position ignoring the extra transparent borders.

  21. Neil says:

    Those transparent borders in Windows 10 confused me when I tried to tile a window to the screen; I expected it to hide the whole desktop. (Also, I can't seem to tile a window from Task manager any more, and the taskbar seems to think I have one more window than I really do.)

  22. ender says:

    > Don't forget that programs could draw into their icons. So an analog clock program could draw an analog clock as its icon, updating it every minute to the correct time.

    I remember Media Player playing the video in it's icon when minimized.

  23. Froyd Ianslip says:

     "and in the case of an auto-hide taskbar, you could see where the taskbar was hiding"

    Poor Taskbar, living my recurring nightmare of walking to the podium, suddenly realizing I forgot to put on my pants… but fortunately there's a curtain over there, I can slip behind that…

Comments are closed.

Skip to main content