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