by doing an strace -ttt -f from another machine it seems the sluggishness
happens around here:

[pid 28353] 1126088564.090674 gettimeofday({1126088564, 90775}, NULL) = 0
[pid 28353] 1126088564.090913 poll([{fd=4, events=POLLIN}, {fd=3,
events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, 0) = 0
[pid 28353] 1126088564.092012 write(3,
"5\30\4\0+\2\340\1\35\1\340\1x\5\0\4\230\4\5\0,\2\340\1"..., 1120) = 1120
[pid 28353] 1126088564.181149 read(3, 0xbff88100, 32) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 28353] 1126088564.181418 select(4, [3], NULL, NULL, NULL <unfinished ...>
[pid 28357] 1126088564.309090 <... poll resumed> [{fd=4, events=POLLIN}, {fd=3,
events=POLLIN}], 2, 5000) = 0
[pid 28357] 1126088564.317235 gettimeofday({1126088564, 325040}, NULL) = 0
[pid 28357] 1126088564.333070 gettimeofday({1126088564, 341042}, NULL) = 0
[pid 28357] 1126088564.349065 poll( <unfinished ...>
[pid 28353] 1126088564.622751 <... select resumed> ) = 1 (in [3])
[pid 28353] 1126088564.622986 read(3,
"]\2d\20\211T\f\0\2\4\4\0\0\0\0\0\0\0\0\4\4\4\4\4\0\0\3"..., 32) = 32
[pid 28353] 1126088564.623285 read(3,
"]\2d\20\211T\f\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3"..., 32) = 32
[pid 28353] 1126088564.623551 read(3,
"\1\1\201\20\0\0\0\0\t\0@\3\4\0\0\0\0\0\0\0,_\1\0pg_\10"..., 32) = 32
[pid 28353] 1126088564.624383 write(3,
"\230\10\t\0\3\2\340\1&\0\340\1\'\0\340\1.\2\340\1\0\0\0"..., 1076) = 1076
[pid 28353] 1126088564.624746 gettimeofday({1126088564, 624849}, NULL) = 0
[pid 28353] 1126088564.624994 poll([{fd=4, events=POLLIN}, {fd=3,
events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], 3, 0) = 0
[pid 28353] 1126088564.625241 write(3, "\222\4\2\0\0\1\340\1", 8) = 8
[pid 28353] 1126088564.625315 read(3, 0xbff8899c, 32) = -1 EAGAIN (Resource
temporarily unavailable)

which seems to suggest it's taking ~500ms to render at least in this case. ~All
of that in the X server ...

Is it possible that Cairo/XRender is being (mis-used) somewhere here ? perhaps
to scale the background, perhaps to re-render that at some sub-pixel offset (in
error) ? [ integer offsets are far faster with cairo ]

'top' shows all the CPU burn happening in the X server so ...

Some more data points
   - with ḃlock color background: instant,
   - with 'tiled' - fast
   - with centered / scaled - turgidly slow...

* H/W - have glx support, ATI Radeon mobility - same effect with it enabled or
disabled.

The worst thing is that the background (presumably set as an XWindow background
or whatever ) is clearly there - since X renders it immediately on switch, so
most likely this is some pointless over-rendering anyway ...

[ was there not a patch in b.g.o to remove that over-rendering / duplication of
pixmap data anyway ? ]

This is most likely fixed by Alex L's focus in/out changes that are in
nautilus-2.12.0 - check RC1

I have 2.12.0 and it is still slow.

The slowness seems to be proportional to the size of the exposed area:  start
with a maximized window and flip to an empty workspace; then start with a clean
desktop but for a little window and flip again to an empty workspace.

So you could just set a breakpoint in the expose handler for
nautilus-icon-container or something like that and see what's up.  I don't know
if the desktop has custom drawing code, but I *think* it's all in
nautilus-icon-container.

*** This bug has been marked as a duplicate of 117163 ***