To be fair, I've noticed a similar lag and 100% CPU usage during resize operations on the ATI open-source driver (hardware: RV635), the Intel open-source driver (hardware: GMA950), and the nvidia binary driver (hardware: GF6200 IGP on Athlon64). The ATI binary driver just lags more severely than everything else.
The best possible solution would be "Option C" above... we need to get the backclear patch accepted upstream. After all, the current behavior of the X server makes no sense: why the heck do you need to read back the contents of video RAM to allocate a new window?
To be fair, I've noticed a similar lag and 100% CPU usage during resize operations on the ATI open-source driver (hardware: RV635), the Intel open-source driver (hardware: GMA950), and the nvidia binary driver (hardware: GF6200 IGP on Athlon64). The ATI binary driver just lags more severely than everything else.
The best possible solution would be "Option C" above... we need to get the backclear patch accepted upstream. After all, the current behavior of the X server makes no sense: why the heck do you need to read back the contents of video RAM to allocate a new window?