HighCPU
On occasion top might report high CPU usage associated with X. We get numerous bug reports about this. There are a number of causes:
Client Applications
In general, most CPU loads are driven by client applications overtaxing the server. Thus, in a way the X load is the sum of client application loads. For instance, the program might be making resource-intensive xlib calls in a tight loop. In almost all such cases, closing the offending program will cause the X load to go back to normal.
The usual process for troubleshooting client load problems is to boot fresh,
Software Rasterizing
Most modern graphics hardware has the ability to perform graphics calculations such as image rasterizing. In theory, X's graphics drivers would rely on the hardware when it needs to do these kinds of calculations, but this is not always the case. When it does them in software rather than hardware, you will see higher CPU loads in X. Check for this via glxinfo:
$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Software Rasterizer
High CPU loads will be noted under this condition especially when moving windows, scrolling in firefox, and when compiz is enabled.
X Server Lockup
The X server itself can get stuck spinning in a loop, which will usually exhibit symptoms including high (>100%) CPU loads. First look at the end of /var/log/Xorg.0.log to see if any error messages are printed there. /var/log/gdm/* is another place to look for error messages.
If none are seen, try exiting the X session; sometimes if X is in a busted state the shutdown routines will complain about it. After restart look at /var/log/Xorg.0.log.old and /var/log/gdm/*.
Other X Server Bug
In a normal, quiescent desktop system, X will require less than 10% of the CPU load. If you've ruled out the involvement of a client application and other causes listed above, the next step is to figure out what X is actually doing during these high load situations.
One approach is to attach to it in gdb (see X/Backtracing for directions) and take several backtrace snapshots at various points in time. Compare the function listing. You may see one function midway up the stack that appears consistently in all the backtraces; that can indicate that X is stuck in that particular function call. Setting a break on that function and stepping through it can provide some additional context as to what X is trying to do.