if you use glXWaitGL() to ensure actual x11 2d draw is complete after a glXSwapBuffers(), then glXWaitGL() will spin in a poll loop consuming as much cpu as it can get its grubby hands on, unlike glXSwapBuffers() alone, which will sleep and release the cpu. i've used glXSwapInterval() to enable vsynced swaps, thus the long pauses/waits. without vsync i also assume it spins instead of sleeping until the hardware lower levels signal that its done with the copy/swap.
i've actually seen this issue for as long as i can remember (years), and it still exists in the 290 drivers.
it's be really nice if glXWaitGL() could behave like glXSwapBuffers() and not poll for power management and simple resource usage reasons. as the logic/code is already there for swapping i would guess it isn't a tall order to move that logic to glXWaitGL() too.