Currently it takes 25 seconds to close a specific HTML file (a few hundred K, only 5000 odd lines) on the kobo glo - which is a 1Ghz cpu. Attrocious. (and the fact it hard-locks the machine whilst doing it is even worse, haven't they heard of threads?)

HTML is not split into lines so your example is missing the point. Rendering html is always a difficult process because the only way to see how the text flows is to ask the text rendering engine to render it, even if the result is known to be off-screen. Then, for each line, there's several extra reflows to figure out best hyphenation position, and then you can move to the next line.

I'm not saying there are no optimisations and other tricks, but:
- this is why epub is split into chapters
- modern web browsers also lock up for considerable time reflowing html
- "threads" is not just a label you slap on a program, and in fact on single-core hardware, interruptable code is probably better than multithreaded code

The Kobo devices do multitask. If you start a WiFi sync, you can keep using the device while that is happening.

Personally, I don't think closing the book and returning to the home page would benefit from multitasking. The delay is probably not in getting rid of the book from memory, but in updating the status of the book, saving bookmarks and annotations and then retrieving the list of books to display. Because they all rely on the database, multitasking or threading might not help. Plus the last step relies on the first being done, so there are some dependencies.

My Glo takes 5 seconds to close a book, which does seem a long time. So, 25 seems excessive. How many books do you have on the device?

Currently it takes 25 seconds to close a specific HTML file (a few hundred K, only 5000 odd lines) on the kobo glo - which is a 1Ghz cpu. Attrocious. (and the fact it hard-locks the machine whilst doing it is even worse, haven't they heard of threads?)