Frame rate problem solved. Not that there ever was a problem.
Turns out, the IGlass frame rate function was returning the actual frame rate - i.e. how often the screen was being refreshed every second. Whereas I wanted to know how often the screen is capable of being updated every second. End result is that it's actually been running ten times faster than I thought it was, which means there's plenty of time for processing between frames.
Part of the plan for the game is to have it multitask, of sorts. So when you're playing, the game should be working in the background. After all, clicking on an interface is not a particularly intensive piece of work so there's no point forcing the player to wait at the end of every day while petty tasks are carried out.
I plan to implement this multitasking by having the game work out when it should refresh the GUI. It's easy to work out how long it takes to render a single screen. Say it takes 5 milliseconds on a bad day. That still leaves about 15 ms of time if you want the game to run at 50 frames per second, so the little background worker guy can just keep checking his watch to see when he should be showing you an update, or when he can do another quick job. Even if he's getting one job done every frame, that's still 50 every second. Those will add up.
It'll get complex when it comes to larger jobs such as calculating an entire match. I'm aiming for a single match to take about an eighth of a second, based on Football Manager's time of 1 second for an exceedingly complex ninety minute match compared to my game's 8 minute fixture. If I could get it in that time on the same computer, I'd be very happy indeed. But that means a single job would take much longer than one frame, so I'd have to be able to chop it up into little pieces.
Ah, design problems. Much more fun than making an editor anyway.