Why do maximized windows lose their title bar translucency?

If you have translucent title bars enabled,¹ you may have noticed that the translucency goes away when you maximize a window. Why is that?

This is a performance optimization.

Opaque title bars are more efficient than translucent ones, and when you maximize a window, you're saying,² "I want to focus entirely on this window and no other windows really matter to me right now." In that case, the desktop window manager doesn't bother with translucency because you're not paying any attention to it anyway.

This may seem like a very minor change, but the difference is noticeable on benchmarks, and, like it or not, magazine writers like to use benchmarks as an "objective" way of determining how good a product is. The reviewers choose the game, and we are forced to play it.


¹The desktop window composition feature that provides the translucent title bar probably has some official name, but I can never remember what it is and I'm too lazy to go find out.

²This may not be literally what you're saying, but it's how the window manager interprets your action.

[Raymond is currently away; this message was pre-recorded.]

Comments (49)
  1. F. Krabbenhöft says:

    The bad thing with this is that the task bar and side bar become opaque as well when a window is maximized – even in a multi-monitor environment. I have always one browser window maximized an one Visual Studio window – that does not necessarily mean I focus on either. I always miss my glassed desktop background that would otherwise be visible.

  2. John says:

    But what happens if I rename explorer.exe to quack3.exe?

  3. Juan says:

    What kind of benchmarks? CPU or GPU related?.

    I have never noticed any speed gain in the gui maximizing the window.

  4. Igor Levicki says:

    Why not check out the OS which had pre-emptive multi-tasking and GUI back in 1985 instead:


    Still boots in under 10 seconds, and it has desktop compositing which works even on seriously underpowered video cards such as Radeon 7000 and 9250, not to mention consuming much less RAM.

  5. James Schend says:


    From reading this blog long enough, I’m guessing the OS sends drawing requests to hidden windows is due to a compatibility fix for some crappy application that depended on this behavior to do some kind of processing.

    Maybe Raymond can confirm or deny this when he gets back.

  6. Adrian says:

    This seems like a reasonable optimization, but it doesn’t work well on a multi-monitor system.

    I typically have a maximized window on the left monitor, and a mess of other windows on the right.  The problem is that I can never tell which window is active.  The title bar on the maximized window is so different from the others, that it always looks special.  That difference, in fact, is far greater than the difference between active and inactive.

    The only way to tell if your maximized window is active is to look at the min/max/close buttons at the end of the title bar.  When scanning windows, though, you’re typically reading the titles, which are at the opposite ends of the title bars from the visual clue.  With a maximized window, that’s a large visual distance.

    Throw in a few Office applications, with their non-conforming non-client areas.  Now you’ve lost any chance of finding the active window with a quick glance.

    Even worse, the ribbon bars on the Office apps tend to drop clicks if the window isn’t already active.  So you move the mouse to the delete button in an Outlook message window and click.  The button flashes (because suddenly the window is activated, so the hot-tracking kicks in).  The flash tricks you into thinking that you successfully clicked the button, and you sit there wondering why the Exchange server is so slow.  Finally the tool tip pops up and you realize what (didn’t) really happen.

    After getting fooled by this a few dozen times, you get in the habit of double-clicking the delete button, and, well, I think you see where this is going.

    All this focus on eye candy, which was probably necessary to convince people that the new OS and Office were different enough to justify an upgrade, really hurt usability and productivity for me.

  7. Raymundo Chennai says:

    Of course you’re not "forced" to do anything.  Which benchmarks are you referring to, anyway?

  8. KenW says:

    @Leo: "God knows why you even brought it up, to be honest."

    Because it’s Igor, whose sole purpose ever in posting here is to be annoying, off topic, and generally asinine.

    Kind of like Raymundo, who posted right after you, only not as cowardly. (At least Igor has the brass b@lls to post under his own name; "Raymundo" not only has to be off-topic and annoying, but has to be insulting in his choice of posting names.)

  9. Igor Levicki says:

    @Leo Davidson:

    My apology, "and it has desktop compositing" should have been "and it now also has desktop compositing (like Vista and Mac OS X)". It wasn’t my intention to imply that it had it from 1985.

    I just wanted to give an example how desktop compositing can work well on low-spec’d machines without such "performance optimizations".

    As for the boot times, if you are booting your A1200 from a floppy then yes it might take a bit more.

    As for the nothing installed .vs. fully-laden (with shovelware I guess), you are right — I recently got a laptop with Vista Home Premium SP1 preloaded with some 20 applications and at least half of them if not more wanted to run at startup. With that in mind, Windows will never boot in under 10 seconds.

    As for your statement "My Vista machine booted to a fully-usable desktop in about 3 seconds…" — Riiight… NOT! I mean, do you really expect anyone to believe that?!? You must be confusing "resume from S3" time with "cold boot after a shutdown" time. Too many pints I guess?

    Finally, saying that this particular GUI feature is a performance optimization when others can obviously do without it using 10 times less powerfull hardware is the equivalent of asking everyone to mock you.

  10. jon says:

    The biggest annoyance from this feature is that the taskbar loses translucency when a window is maximized on any monitor, even one that has nothing to do with the taskbar.

  11. Greg D says:

    Yay!  I missed laughing at Igor’s trolling!

    I wonder if Norman will show up to whine about his SCSI floppy drive on Win95 again?  It makes me giggle.

  12. Nish says:


    "Raymundo Chennai" – it might be someone named Raymond who lines in Chennai, India (formerly known as Madras). I don’t think he was trying to insult Raymond.

  13. Leo Davidson says:

    @Igor Levicki,

    Why would anyone boot an A1200 from a floppy? They had HDDs built-in. My A1200 took a minute to load everything from HDD. I used to have it play full TV theme tunes in the background while it booted. :-)

    And yes, my Vista machine really did boot in about 3 seconds on a fresh install. Have you tried it yourself with decent hardware? (I’m not counting the BIOS part there which no OS has any control over and which varies greatly by manufacturer.)

    "Finally, saying that this particular GUI feature is a performance optimization when others can obviously do without it using 10 times less powerfull hardware is the equivalent of asking everyone to mock you."

    I don’t see what’s wrong, per se, with still optimizing performance even when it isn’t necessary. I also don’t see any relation between "optimizing to avoid wasting CPU/GPU" and "having different minimum requirements." Wasting is still wasting.

    In this particular case I’m not sure the optimization is worth it and I doubt many people would have noticed the hit if it wasn’t there. (I’ve always assumed the opaque borders on maximized windows were an aesthetic choice but I guess Raymond knows better than I do so I’ll take his word for it.)

    What you seem to be saying, though, is that if any competitor (if AmigaOS is even a competitor these days) has lower minimum requirements then doing any optimization at all is an invitation to have people post stupid messages…

    There are so many legitimate things you can bash about MS/Windows (as is true of any complex system, TBH) that it often amazes me that people scrape the barrel. AmigaOS… lol

  14. Tired says:

    Igor wrote:

    "As for your statement "My Vista machine booted to a fully-usable desktop in about 3 seconds…" — Riiight… NOT! I mean, do you really expect anyone to believe that?!?"

    That’s funny because that is what I say when some one says "Hey, my favorite obscure technology was able to do all those things in under 10 seconds on a 10 MHz CPU with 10 MB of RAM back in 1985.  Windows sure does suck!"  I reply "Riiight… NOT!  I mean, do you really expect anyone to believe that?!?"

  15. Leo Davidson says:

    About not painting windows which are no longer visible: That would actually cause problems for the thumbnail (and I think Flip3D, but not sure) features in Vista with composition enabled.

    For example, some apps stop painting when minimized. In the past that was always a good idea since it was a waste painting something nobody could see but now you can see minimized windows. If you hover over a minimized window on the taskbar then you’ll see a thumbnail of it. Apps which keep painting have thumbnails updated in real-time. Apps which use the old Win3.11 style code (which was still included in MFC template projects until quite recently) will replace their window with an icon on a grey background when minimized.

  16. Scruff McGee says:

    I think that maximized titlebars lose their transparency to avoid the issue of having multiple semitransparent objects rendering directly on top of each other, creating a far more difficult to read title.

    In general cases, there is some overlap of window titles, but generally not enough to cause visual definition loss.  With multiple maximized windows however, all titlebars sit at the same location. If maximised windows still had transparent titlebars, the top title in the titlebar becomes much harder to comprehend as it would be rendered semitransparently on top of the preceeding window.

    Try laying the titlebars of multiple windows (non-maximized) directly under each other and you’ll see what I mean. My belief is that it was done purely to increase title comprehension in maximized mode

  17. Simon says:

    Sorry Raymond, but this is bullsh…

    Why would a static translucent title have a performance impact? WDM doesn’t redraw it all the time anyway.

  18. - says:

    Alpha blending in itself isn’t that expensive in modern hardware (well, the glass effect might be). The big gain comes from occluding the other windows so they don’t eat rendering resources and trigger compositions. By making the border opaque, the whole window can cull out of rendering all the windows that are behind.

    That said, I have a thing or two to say about DWM performance. It’s reasonable and shows some effort went into it, but a lot of scenarios make it fail badly. Some examples:

    * A window is only considered hidden when it’s completely covered by a single opaque window. The intersection of multiple windows isn’t enough. In the "maximized" scenario, the screen is covered by two windows: the maximized one, and the taskbar. If there are other windows that cross the maximized-taskbar boundary, they’ll be drawn even though they’re not visible. This also hurts with lots of mid-sized open windows, as no single one is likely to be covered by a single another one.

    * Regardless of wether a window is visible or not, the app keeps getting drawing requests on invalidation. This is a real deal-breaker for me, since of you have a window open that takes substantial CPU time to update, you’ll be paying that time continuously, unless you manually minimize the window. I have strong evidence to think that just requesting redraws when the window is visible would work better overall (note that you wouldn’t see garbage on reveal like you’d get without DWM – at most you’d get an old version for a split second)

  19. SuperKoko says:

    "My belief is that it was done purely to increase title comprehension in maximized mode"

    You’re probably right, however I see another advantage:

    By maximizing a window, I want to hide other windows whose contents or animations would distract my attention.

    Anyway, it’s difficult to believe that such a simple usuability feature is so criticized.

    I’m SURE that, if transparency was enabled in maximized windows, it would be even more criticized.


  20. wickens85@gmail.com says:

    On XP, the Google Sidebar becomes opaque when you maxamize a window too.

  21. KJK::Hyperion says:

    Simon: if it’s translucent, whatever is "under" it has to be redrawn, and the translucent effect applied to it

  22. J says:

    "On XP, the Google Sidebar becomes opaque when you maxamize a window too."

    On my system, it becomes much less transparent, but not opaque.

  23. - says:

    Leo Davidson: You misunderstood. The issue at hand is whether it’s correct to keep sending paint messages to applications even though their windows aren’t visible at all. If you invoke Flip3D or a thumbnail comes visible (for example via the taskbar preview), then fine, start painting so the animations work.

    But in the normal case where it won’t even get to the screen, what it gets you is constant CPU (note: not GPU) load per each non-minimized window that is playing any sort of animation or otherwise painting anything.

    In fact, having the DWM invalidates a Raymond recommendation, namely: http://blogs.msdn.com/oldnewthing/archive/2003/08/29/54728.aspx

    That trick won’t work anymore: no matter how well covered the window is, it’ll still get WM_PAINT messages.

    If you want to see this in action, visit http://bubblemark.com/flex.htm and check the CPU usage with the animation visible. Then, with DWM disabled, cover all of the animation with other windows (you can even use multiple non-square windows, as long as all the pixels get covered). CPU usage will drop drastically. Now try it with DWM enabled. The only way for the CPU usage to drop is to minimize the entire window.

    The really scary stuff happens if you open multiple windows that do this, and have them all maximized. With DWM, each of them is hammering the CPU like there’s no tomorrow. Using the classic sane model, only the foreground one will be drawing.

  24. Leo Davidson says:

    @Igor Levicki

    I still have my A1200 and I can assure you it doesn’t boot in 10 seconds. It takes about a minute to boot, if not more.

    Same with any OS once you’ve installed all your tools, drivers, anti-virus and so on.

    My Vista machine booted to a fully-usable desktop in about 3 seconds when it was freshly installed. (Now it takes ages because it’s got to load all my stuff.)

    I really wish people would stop comparing the boot times of OS with nothing installed on them (especially OS that don’t even *have* drivers and software to install, lol) with a fully-laden install of another OS. It’s just stupid.

    For the record, I loved AmigaOS back in its time. It was well ahead of Windows 3.11. These days, though, anyone who talks about it is either taking the mickey, as we’d say in England, or delusional. Let it rest in peace.

    AmigaOS has only *just* (2008) got desktop composition, too. Your post made it sound like it has had it since 1985. God knows why you even brought it up, to be honest.

  25. microbe says:

    I maximize my browser so I could see more of the web page. It doesn’t mean I don’t care about other things.

    The real question is of course why it’s so slow in the first place.

  26. Leo Davidson says:

    -: I see what you mean.

    One thing that I think is missing (at least I don’t know a way to do this) — whether or not composition is enabled — is a way for an application to tell if (part of) its window is really visible or not.

    (IsWindowVisible just checks window styles, not whether something is obscured. That is useful in other situations but there’s no IsWindowObscured or similar AFAIK.)

    Still, I wonder how good it would look if you hovered over the taskbar and had to watch as the thumbnails were slowly drawn, possibly by an application that had been paged out and was very slow to paint? It’s a good thing that the thumbnails appear instantly because they’re already cached, I think. At the same time, it would be good if paint-intensive apps such as animation players could detect that nobody was looking at them and stop animating.

    Ditto when the screensaver kicks in. (I don’t know if it’s related but screensavers seem to continue running when the monitors turn off, too. I used the Vista Power saver but I noticed my GPU fan was still going minutes after the monitors went black. That seems wasteful.)

  27. Miral says:

    I too have multiple monitors, and it really annoyed me when my animated desktop on both monitors would freeze (and no longer be visible through the taskbar) when I maximised a window on only one monitor.  It basically completely defeated the point of having an animated desktop in the first place… which is why I turned it off again.

    Now I’ve disabled DWM entirely, because it was causing too much CPU lag (and memory consumption) with the constant redrawing of nonvisible windows.

  28. chrisg says:

    this was also to provide a visual effect that the Vista design team wanted; to focus your attention on the maximized app.

  29. - says:

    Still, I wonder how good it would look if you

    hovered over the taskbar and had to watch as

    the thumbnails were slowly drawn, possibly by

    an application that had been paged out and

    was very slow to paint?

    Again, that’s not it. The DWM always keeps a valid window representation at hand, on video memory (well, there’s a bit more to it than that, but still…)

    This already comens handy when a window is minimized: the window can’t be painted on anymore (hence animations freeze), but you still have the last known image available.

    What would happen at worst is that you’d see an old representation of the window contents (what was available the last time the window was visible) until the app finished painting. On most cases this wouldn’t be noticeable at all.

    Take a look at http://blogs.msdn.com/greg_schechter/archive/2006/03/25/561167.aspx if you want to learn more about how the DWM works, it’s explained rather well there.

  30. Tanveer Badar says:

    I like eye candy more than responsiveness decreasing by 200 ms (wild guess, sue me!).

    That’s why my windows are never maximized in the traditional sense, instead I stretch them as far as possible and still have alpha blended border.

  31. JP says:

    Well, this post certainly flies in the face of all previous MS commentary that said this was a design-driven decision. Isn’t this kind of post five years too early? Vista is still the current Windows you know!

  32. - says:

    Leo Davidson: Still not managing to get the message across it seems.

    What I’m saying is to send a WM_PAINT message when, if and only if, the window is actually drawn in some form in the screen. So when you hover over the taskbar and the thumbnail appears, that’s when you send pending WM_PAINTs (and new ones upon further invalidations). Ditto when Flip3D or the like is invoked and you can actually see the window. But when you can’t see it at all, it doesn’t really make sense to waste CPU for it.

    It’d work exactly as it does now, with the exception that if some app is slow at painting, you’d see the old representation for a split second. Note that this usually won’t happen (to put things into perspective, without the DWM, when a window becomes visible it has to draw itself completely, and it’s not terrible at all – in many cases it appears instantaneous – and with the DWM, you see a valid (old) window, and not garbage, until that happens)

    Minimized windows are another problem, since (IIRC) they get a very small "placeholder" size and therefore can’t be drawn to, so the DWM holds on to the latest known representation. I’m actually glad this happens as it leaves the door open to manually minimize windows to stop the paining madness.

  33. shane says:

    If this was done for performance reasons, then why isn’t it disabled all the time?

    Maybe because people want the effect of alpha blended windows and are prepared to pay the performance price?

    If that’s the case, then why disable it when maximized for performance reasons? it makes no sense.

    I really doubt it was done purely for performance reasons, and this is just a side effect of the visual effect they are wanting.

  34. ender says:

    I just wish there was some way to enable desktop composition without the Aero theme. I want to have full control over the interface colours, and when using Windows Classic, applications are noticably slower to redraw on Vista x64 than on XP x64.

  35. Leo Davidson says:

    "The DWM always keeps a valid window representation at hand"

    It doesn’t, though, if it has stopped sending WM_PAINT in response to the window being invalidated.

    Consider a minimized progress dialog, or a video application, where you actually *want* to see an up-to-date thumbnail to check on something. e.g. To see how far the progress bar has reached or if the adverts have finished yet.

    If DWM just shows you a snapshot of the window at the time it was minimized or obscured 5 minutes ago then that’s not useful in that situation.

    (For apps that detect being minimized and stop painting that’s what happens.)

    Of course it’s a trade-off. Often you don’t care about such things and it’s a waste of time painting windows that are not visible.

    Ideally it would be something the application could control and there would be a way for apps to know if a) their thumbnail is being displayed despite them being minimized and b) if they are completely occluded by other windows despite not being being minimized. Then each app could decide, possibly with user settings to override it, what is most appropriate.

    I’d also say that this problem doesn’t affect many apps, IMO. If you’ve got something paint intensive then chances are it’s in the foreground and you’re looking at it and you pause or close it when you’re done. The only problem I’ve ever had with this type of thing is poorly-made Flash advertising that takes up a lot of CPU power in idle browser windows/tabs. That’s one of the reasons I block Flash by default. Problem solved, for me at least.

  36. DCMonkey says:

    The latest e7 blog post presents a different reason:

    "An issue we’ve heard (as recently as the comments on the taskbar post!) with maximize in Vista is that the customized glass color isn’t very visible, because the windows and taskbar become dark when a window is maximized. (In Vista you can customize the glass window color – and in 29% of sessions a custom color has been set).  The darker look was used to help make it clear that the window is in the special maximized state.  This was important because if you don’t notice that a window is maximized and then try to move it, nothing will happen – and that can be frustrating or confusing.  For Windows 7 we’re looking at a different approach so that the customized color can be shown even when a window is maximized."


  37. DCMonkey says:

    Though maybe that only speaks to why they chose black, not why they chose opacity. Even then I’ve seen it mentioned more than once that black was chosen to give emphasis to the window content.

  38. KenW says:

    @Nish: ""Raymundo Chennai" – it might be someone named Raymond who lines in Chennai, India (formerly known as Madras). I don’t think he was trying to insult Raymond."

    Hmmm… What are the odds that someone who posts trollish messages on a blog belonging to *Raymond Chen" would have the name "Raymundo", live in Chennai, India, and decide to make his posts (coincidentally, of course) as <Name><City>…

    If you like those odds, I’ll bet you’re willing to help important people in Nigeria get their vast fortunes out of the country, too.

  39. Marc says:

    ender: I too would like to use the DWM and still use the classic theme. I like taskbar previews, not keen on big title bars and transparent windows.

  40. Marc says:

    According to http://blogs.msdn.com/e7/archive/2008/10/01/user-interface-managing-windows-windows.aspx

    "The darker look was used to help make it clear that the window is in the special maximized state. This was important because if you don’t notice that a window is maximized and then try to move it, nothing will happen."

    Great blog that btw, I highly recommend it.

  41. Ens says:

    You know, it’s quite possible that what Raymond said is true AND what e7 says is true.  It could be that the combination of two issues pushed non-transparency.

    But the e7 discussion makes it sound like we’re probably going to have transparency-on-maximize in Win7.

  42. manicmarc says:

    Ens: Yes I’m sure there are multiple reasons. I just found it interesting that the W7 team didn’t mention the performance reason.

    I don’t think we will get transparency-on-maximize in W7, we’ll just get a colour we selected rather than black. I hope toolbars changes to match this colour scheme too. Vista looks odd unless your colour resembles Blue, because all the toolbars are blue.

  43. Leo Davidson says:

    -: I get it completely. I agree that what you propose is better than what we have now. However, you seem to be ignoring my point about swapped-out apps and/or downplaying the long (10s or more) delays that can occur when an app that was swapped out long again is asked to paint again.

    With composition enabled, the only way for an application to be asked to paint itself without its window being moved is for that program (or some other, but that would be bad) to explicitly invalidate its window (or explicitly paint to it). That only happens when the program is active, i.e. not swapped out. IN GENERAL I would much rather that applications be able to update their cached window representation when they are active, since it’s cheap to do so. Then thumbnails and restored windows can appear *instantly* even if the app is swapped out later due to going inactive or low memory.

    Most programs do not update their UI constantly or expensively. Some do but I think they are the exceptions. Thus it would make sense for there to be an API so that those exceptions could turn off their painting until it was needed while every other app could simply paint as soon as they needed to. Wouldn’t that be the best of both worlds?

    As I said before, I cannot think of any problematic apps other than Flash with bad advertising in idle browser windows/tabs.

  44. Igor Levicki says:

    Leo Davidson said : "And yes, my Vista machine really did boot in about 3 seconds on a fresh install."

    Sorry. No way. Boot time = time from hitting the power switch until you get usable desktop (the one you can click an icon and launch an application).

    Leo Davidson said : "Have you tried it yourself with decent hardware?"

    I always have decent hardware. I recently tried Windows Server 2008 x64 w/SP1 on 4 socket 6 core Dunnington setup (that is 24 cores at 2.4GHz) with 8GB of RAM and RAID0. It still didn’t boot in 3 seconds even if you disregard BIOS initialization time.

    Leo Davidson said : "I don’t see what’s wrong, per se, with still optimizing performance even when it isn’t necessary. I also don’t see any relation between "optimizing to avoid wasting CPU/GPU" and "having different minimum requirements." Wasting is still wasting."

    Don’t get me wrong — I always encourage optimization to avoid being wastefull. However, in this particular case they have "optimized" just to meet minimum performance requirement so the UI doesn’t drag like a dead horse on lower spec’d machines. That is a marketing-driven optimization, not engineering driven and I cringe at the thought of that.

  45. SuperKoko says:

    "I recently tried Windows Server 2008 x64 w/SP1 on 4 socket 6 core Dunnington setup (that is 24 cores at 2.4GHz) with 8GB of RAM and RAID0."

    1) Windows Server 2008 isn’t Vista.

    2) Boot time highly depends on hardware (other than CPU). It’s not always the fast hardware that boots quickly. On the other hand, a computer without much hardware may boot faster.

    Side note: BIOS initialization times are extremely variable. My sister’s laptop POST is almost instantaneous (2 seconds), while mine is very long (39 seconds).

  46. Craig says:

    For what it’s worth, I’ve been extremely frustrated by title bars changing to opaque black when a window is maximized. The way they did the visual styling makes it almost impossible to tell which window has the focus, which is particularly bad in multi-monitor situations. Also, it makes the UI feel inconsistent. This seems like a perfect place to give the user a choice.

  47. caywen says:

    Sounds like another useless defense of a useless design decision. Am I to believe the DWM is so inefficient that a single translucent caption would cause significantly more performance issues than having 20 non-maximized windows open?

    I think the KISS principle should state that a maximized window is a non-moveable window that covers the largest non-reserved rectangle of the screen, and is the same as any other window in almost every other respect.

    Finally, I thought Microsoft prided itself in thinking long term and wasn’t victim to reviewers would ding the OS on a tiny performance hit on maximized windows. It’s not like Vista got good reviews for performance anyways.

  48. Jolyon Smith says:

    Amiga A1200s did not have HDDs built in.  At least, not in the UK.

    I know, cos I had to source and install a 2.5" drive in mine myself (back when such things were a real novelty) … and it was a monster.  A whopping 60MB drive (yes "M"B) that I never, ever managed to fill.

    Mind you, this was also at a time when you could set up complete Windows install to boot from a 20MB PCMCIA flash-drive and still have room left over.


  49. Matt Craighead says:

    The difference I always notice under XP is that maximized windows lose the rounded corners.

    In case you haven’t ever worked on a graphics driver: rounded corners are a pain to deal with!  When you build a window’s clip list (a list of rectangles), back in the Win2K days it never got too long except in extreme cases.  With rounded corners even simple overlapping window cases can have lots and lots of clip rectangles.

Comments are closed.

Skip to main content