Here some hints as the result of our “off-forum" email exchange and discussion on above topic:
A combination of many things created the above reported strange behavior,
which is solved now!If you want to see (as proof ;-) a big book with >300 pages of high resolution, composed out of single swf files, working pretty smoothly (already with v2.0.2, i.e. including search support!), have a look here:
Demo Book (300 pages, with search)And try out soom (scroll the wheel), liquid scaling (resize the window) and gallery mode with big magnification of up to factor 5 (click inside a page)!
Hopefully the following tips will help you also to achieve a fast flipping book and to adjust the parameters correctly!
Resolution, CachingThere is almost no real impact of the time it takes to show the pages and the resolution and size of the image/page (as long as the internet connection is pretty OK ;-).
Of course a lower resolution page has a positive effect on the time the first page shows up. And also on the time it takes to fill the cache again if jumping to a page outside the cached number of pages (fast flipping across that number of pages has the same effect as “jumping”).
But since a lot of other things happens the first time a book is opened, the download time of the page is only a fraction of that time.
The next pages then are cached (you can parameterize the number of cached pages), and as long as you browse reasonably normally (read before flip to the next page without delay), the next pages should be available in an instant.
Independent on the size of the page/image, because all happens in the background.
That's why liquid scaling is such a great thing and should be preferred instead of gallery mode now (which was the only chance to “zoom” in version v1.38!).
Gallery mode still could make sense
- in case you have a real high resolution picture and want to offer the option to see every pixel (like in the case of a 12+ MPix photo), or
- if you have vectorized text (swf or png). Now with a zoom up to factor 5 in gallery mode you can make small fonts readable for handicapped people also on high resolution monitors.
MegaZine3 ParametersYou most probably know that a lot of things can be parameterized. A big benefit, but dangerous!
If you do not need to change the default values (which all have very meaningful settings!), it is best to not touch them. So not even list them up in the [book] declaration.
Keep it streamlined, slim.
As small as possible!
Many parameters have an impact on performance. In certain, special cases you can achieve improvements, but if you’re not very experienced, chances are high you turn it to the worse! Avoiding to play around with the parameters reduces risk of problems and keeps the file better readable! Many of the “problems” reported in this forum are results of certain “creativities”!
My suggestion is to leave all parameters at their default value first.
Only in case you have the real need to tweak/change something, and you really, really (!) want a different behavior and understood the parameter and know what you are doing, then you should touch it ;-)
But even then: please…one by one!
And check after each change, if the behavior is as expected!
Doing several changes at a time is the best way to waste time.
How to best set pagewidth and pageheightThere are several options to define heights and widths. Admitted, can be confusing at the beginning.
Hopefully the following explanations help to avoid some typical traps.
My guidance is:
Make pagewidth and pageheight in case of PDF/SWF files identical to the resolution of your real pages; by the pixel!
Do not use any height or width parameter in neither <page> nor <img>!
Everything else results in overhead because MegaZine3 then had to scale, and every scaling takes time!
Only in very specific situations you might consider using those parameters, like defining height and width parameters for an image can help when you quickly want to put photos of "incorrect" size/dimensions into a book and cannot resize those photos at the moment (e.g. if you have no access to the sources, cannot upload because of reduced bandwidth and alike).
Then you could force with these parameters an image with whatever resolution/dimension to fit onto a page.
Be careful , though: if you pick the wrong values, you will get distorted images. Using a percentage like 50% or so in that case instead of fix values, might be the better approach.
Make the resolution of your page big enough so it is comfortably readable at full size. If 1280 pixel are needed for that, it does not really make sense to only offer 800 pixel first and with that force the visitor to use full resolution via gallery mode and hires! With all the disadvantages of the gallery mode: slow, no caching, no interaction, no page flip, … all the things you complained in the past!
With liquid scaling and zoom you now have all the power you need!
With automatic adjustment to the resolution of the visitor’s monitor.
The best approach is to either know what size your source docs are and set the book to that size, or define the book size and make your images that size.
If you know (or can safely guess) the minimum resolution of your user's screen, you also can set minscale appropriately. A good first approach is to set it to minscale="0.5" or "0.25" (see below).
If you go into full screen mode using the button in the navigation bar (not to confuse with gallery mode in full screen!!), you have maximum resolution and still can navigate and use all book features!
Liquid ScalingThis automatically is enabled whenever the parameters maxscale and minscale in the <book> declaration are set to different values.
Maxscale shouldn't be bigger than 1.0; because otherwise you see artefacts at e.g. the book edges!
Only if you have small photos and if you expect someone with a high resolution screen seeing those big enough... then you might consider to use a factor of 2.0
Minscale should be set at a value that is wither 0.5 or 0.25 to avoid waste of computing power and not to get artefacts by interpolations.
If you then zoom from min to max (the extremes, i.e. from minscale to maxscale), there is no need for any anti aliasing calculations! And Text looks sharp and clear even if presented as bitmap like jpg files (compared to vector text as in swf or png). And with the next version v2.0.2 available soon (tomorrow?!) you even can select those values with e.g. a double click (see hint in other post some hours ago).
Everything in between those values will result in fuzzy characters. That's in the nature of things, based on optics and physics and mathematics. Only with big effort you can minimize those effects (like with anti aliasing algorithms, fractal or similar technologies).
Hopefully this helps to understand the logic of Megaine3 a bit better!
