That's most likely because of the (at the moment pretty rudimentary) liquid scaling. I'm planning to "unlock" the gui from the pages in a future release so the shrinking of the menu won't be a problem anymore.
What you can do for now:
Either give the Flash element in the HTML a fixed size instead of a relative (percentual) one. That means
a) changing the width and height in the swfobject.embedSWF(...) call and
b) changing the width and height in the css (in the #megazine class)
to a fixed value that leaves enough room for your book.
I probably shouldn't have made it that way around the default yet...
The performance degeneration stems from the fact that if the book grows this big, per default not all pages are kept in memory at a time (else the requirements for ram could be quite high). You could try increasing the number kept in memory, so that all pages are kept in memory, using the
maxloaded attribute of the
book tag. After that open the book, press
# to open the console, then enter
info to see how much ram is used (note that that will be the ram used by all flash objects opened in the browser, though, so e.g. if you have youtube opened in another tab that will count into that value as well).
I'll at least add a parameter for the next version, to set that pages may only be loaded when no pages are turned. That will obviously increase the chance that an blank (unloaded) page is shown while flipping many pages at once, but it will certainly increase performance quite a bit during that time.
The last part with the zoom getting off-screen I can't explain. Do you have a link to demonstrate the effect?
