Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Enabling window buffer compression System
The window server has a cool feature in OS X 10.1 that isn't enabled by default (though it will be in an upcoming update, as I understand it): window buffer compression.

A little background. Under OS X, the contents of each window are saved in a buffer, so that they can be updated instantly, and also so that the cool transparency effects in Aqua are possible. This is a good thing, to have a fully buffered window manager -- however, it uses a lot of memory.

In 32 bit mode ("Millions" in System Preferences), a window that is 800 pixels wide by 600 pixels high uses up 1.9mb of RAM. When you consider that there are usually over 100 windows open when you're using OS X (not all windows are visible), you start to realize that this can start to add up in terms of RAM usage.

The more windows you open, the more RAM they use up, the more that virtual memory will have to page in and out while you use your applications to do work. This can cause slow-downs as the disk grinds to do the virtual memory paging.

So what Apple did was they implemented a compression mechanism into the window server. When a window's contents haven't changed for a given period of time, the window server compresses them, so they take up less memory. Since it uses a compression method that doesn't require the buffer to be fully decompressed to do compositing (dragging a window around, updating the screen, etc.), you won't notice a slowdown with this compression turned on.

In fact, because less memory is being used up by the window buffers, more RAM will be available for your applications, with will mean less virtual memory paging, and may in fact result in speeding up your machine. Additionally, since less data needs to be read (it is compressed, after all!), things like updating windows may be faster as well.

If you are a power user who has lots of windows open, you might consider giving this hack a shot. I'm using it, and getting compression ratios of about 8.5:1 (in other words, my window buffers are using 8x less RAM than they normally would).

Read the rest of the article for the details on implementing window compression.

Andrew Welch / el Presidente / Ambrosia Software, Inc.

Now then, onto the hack! First, open up the Terminal application (found in /Applications/Utilities/) and type:
sudo pico /library/preferences/
(you'll need to enter your admin password in order to proceed). Move the cursor down below the first <dict> tag, and paste the following text in:
Then hit Control-X to exit pico (hitting the Y key to save the changes before exiting when it asks you), then log out and back in again, and ta da! Compressed window buffers. Enjoy...
  • Currently 3.00 / 5
  You rated: 3 / 5 (4 votes cast)

Enabling window buffer compression | 16 comments | Create New Account
Click here to return to the 'Enabling window buffer compression' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Won't this slow things down?
Authored by: moki on Oct 08, '01 05:30:48PM

It will actually be faster, for the two reasons I mentioned. First, less swapping (which will happen somewhat, regardless of how much RAM you have).

Secondly, consider that most modern CPUs are memory bandwidth-bound. When you need to update a window with a 200K buffer, you have to read in 200K of data, then write out 200K of data.

The vast majority of the time spent doing this copying involves the CPU just sitting and spinning waiting for data. If you use the compressed buffer, and a reasonable 10:1 compression ratio, you only need to read in 20K of data, running it by a simple algorithm, and write out 200K of data.

Since your are 10x less memory bound, and since you're using CPU cycles that would have been wasted anyway, you are faster. This is the same principle behind RLE blitters, etc.

[ Reply to This | # ]
The Numbers...
Authored by: cj69collins on Oct 09, '01 08:06:29AM

I have tried your little trick and, though I have seen some improvements, I am not thoroughly convinced that this is as much of an improvement as one might think, especially for programs which are classic memory swine: the web browsers, namely IE. I often have four to eight windows open at the same time, switching between windows routinely. I wonder if that would throw a kink into the mamagement scheme. I will need to conduct more testing to be sure.

My question is: How did you arrive at the numbers in your tag, and how did you conclude that the memory reductions would be on the order of 1/8.5?

[ Reply to This | # ]
Authored by: charlietuna on Oct 09, '01 09:06:54AM

For those of us who are skeptical, how would we know that our windows are getting compressed? How does Mr. Welch know that his windows are getting such-and-such compression?

[ Reply to This | # ]
Authored by: Anonymous on Oct 09, '01 11:25:59AM

the compression:
start your console and monitor console.log.
from time to time you'll see a line stating that a "compressed window was flushed" by the windowserver.

the ratio:
well, i guess it's in the numbers he provided. look at the line that contains "ratio".

not too sure about both, though... :)

i noticed that app-switching is A LOT faster than before. may be imagination, but who cares? ;) if it *feels* faster, it's ok with me.

[ Reply to This | # ]
It works for me!!!
Authored by: sungwoo on Oct 09, '01 02:09:34PM

I tested with eight applications which mixed as a carbon, cocoa, and classic applications.
On my Wallstreet 233MHz, it works as Mr. Welch claimed. Way faster than before!!
I can say that the switching app shows me an instant redraw. hmm...
However, I am not sure this really reduce the RAM usage. Maybe I tested with too small number of applications?

Also, I have a same question.
Why the ratio (8.5:1) is specifically suggested?
And if I wanna change it as 10:1, what value should I use? (any example plz?)


[ Reply to This | # ]
Authored by: werikblack on Oct 24, '02 12:59:50PM
The information given is accurate. If you look at top, a lot of times the processor's doing almost nothing, and the bus going to the processor is saturated. Just doing the math, the processor is running at 2x1.25 GHz on the high-end machines, but data is only getting there at 167 MHz. Granted, this is oversimplified and doesn't take into account a number of other factors, but that's a pretty big disparity. To verify window buffer compression, you have to have the developer tools installed.
  • Launch /Developer/Applications/Quartz Debug.
  • Click "Show Window List."
  • View values in the kBytes column. These tell how many K RAM your windows are using
If the value has a "C" appended to the end of it, this means the window buffer is compressed.

[ Reply to This | # ]
So far all I get is a crash
Authored by: sjonke on Oct 09, '01 03:52:50PM

... on my 2000 iBook running 10.1 w/ 320 MB RAM. I tried enabling this as instructed, but I never see anything about window buffers being compressed in the console window. Perhaps all this means is that in typical use I have plenty of RAM to handle everything uncompressed. What I have gotten since setting this feature on, though, is an ugly system freeze at the screen saver's password entry screen. The OK button looked like a mess of pulsing, static-y colors and I got an endless spinning cursor. I don't think this happens every time, but it happened in only a few uses and I have never seen it before. Obviously I'm not sure it's related, but since this feature doesn't seem to do anything for me, you have to wonder if there is good reason why it isn't enabled by default.

[ Reply to This | # ]
Authored by: moki on Oct 09, '01 04:03:56PM

I arrived at the ratio I mentioned by querying the window server programatically to see what the current compression stats are.

A simple way to see what windows are compressed is to run QuartzDebug (installed with the Developer Tools), click on "show window list" and look under the kByte column -- anything with a C after it is compressed.

BTW: the "ratio" in the plist is the minimum compression ratio that it needs to get in order to keep a window compressed; this is different from the actual compression ratio that you'll get, which varies somewhat depending on your window usage.

[ Reply to This | # ]
Authored by: sungwoo on Oct 09, '01 04:29:50PM

I took a look Quarz Debug, and most compressed buffers are found from Explorer.
With your tip, also menu pull-down and typing in Explorer getting more smooth and faster.
Even now I got many pagein and out, still very smooth. It is amazing.

BTW, if I want to change the ratio as 10:1, how much value should I modify from your example?

[ Reply to This | # ]
Authored by: moki on Oct 09, '01 07:16:41PM

you should not change the ratio listed -- again, it is the *minimum* compression ratio that will be used. In other words, if a window can't be compressed more than 1:1, it won't be compressed at all.

You cannot affect how much window buffers are actually compressed -- this is a function of what is displayed in your windows, and is not anything you can control.

[ Reply to This | # ]
No internet connect
Authored by: bilca on Oct 11, '01 04:29:52PM

I've tried this hint on my iceBook and couldn't use internet connect with a Draytek miniVigor. Removing the lines, restart and it worked again.

Tip: you can make the changes with TextEdit if you don't like pico


[ Reply to This | # ]
Does 10.1.1 (or another) update kill this?
Authored by: jo5_h on Dec 13, '01 02:17:54PM

i know that i applied this tip on my TiBook shortly after installing 10.1, but i've been experiencing some odd drive thrashing issues, as well as a problem w/ my system not sleeping unless i choose Sleep from the Apple menu, so i thought i'd try disabling the buffer compression. well.. it seems that the code listed here is no longer present in my file. odd! i can only assume that an update i've applied since the time i applied this tip has overwritten the file i'd updated, since i've not done so myself. has anyone else had a similar problem?

[ Reply to This | # ]
does it work with 10.1.2?
Authored by: Hugo on Jan 23, '02 04:26:45PM

does anybody know if this will work with 10.1.2? Or is the compression yet implemented?
The only window-concerning messages I get in the console are these:

Jan 23 21:41:27 localhost WindowServer[68]: CGXDisableUpdate: Updates disabled by connection 0x3d03 for over 1.000000 seconds

Jan 23 21:52:41 localhost WindowServer[68]: CGXDisableUpdate: Updates disabled by connection 0x5b03 for over 1.000000 seconds

Thanks for any hint

[ Reply to This | # ]
Mine still works.
Authored by: serversurfer on Jan 23, '02 09:31:57PM
My /library/preferences/ has the entry listed above, but I'm not sure if I put it there or an updater did. (I know I followed this tip when it was posted, but I don't know if any updaters have subsequently altered the file. It's stamped Nov 16.) You can see if yours is compressing by using the QuartzDebug tool as described in the reply above.

[ Reply to This | # ]
re: Mine still works.
Authored by: mhagers on Mar 07, '02 10:12:52AM

I just did this on a machine that has 10.1.3 installed, and never had this hack applied before. I checked for references to it, by searching the file for several words appearing in the tag. There weren't any.

So I assume that: A) this is still not implemented in the current OSX version, and B) that updates leave this hack alone. I can check B tonight on my home machine, where I have updated to 10.1.3 some time after installing the hack.

[ Reply to This | # ]
re: Mine still works.
Authored by: delink on Apr 30, '07 03:40:46PM

does this work in any current versions of OS X? google doesn't find any references beyond 2002, so i'm assuming not.

[ Reply to This | # ]