After experimenting with a long running average at maxed out FPS and a variety of map sizes, 128 seems to actually be a good size to use if only drawing bits of world with stuff in it. 64 actually did even better in some situations, but significantly worse in others (lots of land, zoomed out).
/**
* \page faq QuaZip FAQ
*
* <!--
* \ref faq-GPL "Q. Is it possible to release an LGPL version of the QuaZip?"
*
* \ref faq-non-QIODevice "Q. Is there any way to use QuaZipFile in Qt where you are supposed to use normal (non-zipped) file, but not through QIODevice API?"
* -->
*
* \anchor faq-GPL Q. Is it possible to release an LGPL version of the
* QuaZip?
*
* A. I do not know much about licensing, so I can answer for sure, but
* QuaZip was developed using Open Source edition of Qt, so I see no
* way it could be released under anything except GPL.
*
* \anchor faq-non-QIODevice Q. Is there any way to use QuaZipFile in Qt
* where you are supposed to use normal (non-zipped) file, but not
* through QIODevice API?
*
* A. Usually not. For example, if you are passing file name to some
* database driver (like SQLite), Qt usually just passes this name down
* to the 3rd-party library, which is usually does not know anything
* about QIODevice and therefore there is no way to pass QuaZipFile as
* normal file. However, if we are talking about some place where you
* pass file name, and then indirectly use QFile to open it, then it is
* a good idea to make overloaded method, which accepts QIODevice
* pointer. Then you would be able to pass QuaZipFile as well as many
* other nice things such as QBuffer or QProcess.
**/