Hi, A little bit of empirical measurement by Juho Snellman reveals that in certain circumstances, such as waving the mouse over the gsharp window, mcclim under sbcl spends 70% or so of its time in bignum operations related to converting floating point numbers to rational ones. I believe that this is an artifact of the "permissive" coordinate type (currently set to real, apparently after a version of cmucl started doing some kind of type checking or inference). Attached is a patch which restores the double-float coordinate type, along with at least some of the necessary coercions here and there. I'd probably not merge this directly, because I'm still confused over when something is a coordinate and when it isn't. I believe that bounding-rectangles and regions are coordinate-based, and that output-records are rational-based, at least in terms of their position. If this is the case, I'd suggest adding completely separate slots for the two "worlds"; rather than having coercions on accesses, there would be coupled setter methods. In this patch, I've instead been somewhat conservative: anywhere where I was uncertain what was happening, I inserted a call to the COORDINATE function. This version has survived a certain amount of rudimentary testing in the listener and gsharp. I'd be interested to know if there is any perceptual speed change, and also whether there are coordinate-related bugs remaining. [ this patch was driven by a branch of SBCL in CVS tagged as clos-typechecking-branch, which includes type checks for most (setf slot-value), (setf accessor) and make-instance calls ] Cheers, Christophe