Optimising Performance

[MPete]

THE PROBLEM
I launched my first megazine last week. The verdict?

• WOW! this doesn't work very well / swf page flipping is crashing my browser
     clearly a concern and need more detail. Possibly older browser/flash version, memory leak, cache?
  
  
• It's too slow / very slow performance / too slow to load
     internet speed and overall file size
     cache amount, file size, vector content, page size, plugins loaded, liquid scaling
  
  
• swf is not a suitable/practicle format / not a good technology, this will limit your readership / where can I download the pdf?
     what are you living under a rock? Flash is application-rich and is making more of an impact then the "safe" pdf option and definitely a relevant technology
  
  
• mine seems to work fine / works nicely for me / not a problem my end
     with all this negative feedback, the same files run seamlessly for some users (possibly better computer speed, operating system browser/flash version?)
  
  

RELATED DISCUSSION

• What are the suggested maximum values or limits?
• Megazine Performance
• very slow page turning using swf's..very high CPU time
• High CPU-Usage during Pageflip
• Caching Pages
• performance and swf's
• Bug: Book hard cover gets stuck when flipping
  

DEBUGGING/TROUBLESHOOTING
- console plug-in You can use the MegaZine console plug-in to pinpoint potential bottlenecks (include "console" as a plug in in the mz3 file, press # to load)
- Speed Tracer Google Chrome Extension - GET IT NOW! details exactly when the CPU is being used up, painting, millisecond logs on all aspects of the site so you can tweak to your liking and export reports to help in development and explaining how things are failing.
- Firebug Firefox plugin - lists potential holes, script errors, speed latencies
- YSlow Firefox plugin - great overview of loading speeds etc


KNOWN BUGS
As MegaZine3 continues development, it can only improve with user feedback and development discussion to pinpoint bottlenecks, bugs and suggestions for improving speed via compromises or setting adjustments.

• Memory leaks
• Known Flash bugs, unavoidable but to consider a work around

RECOMMENDED LIMITS
Work within the functional limitations of maximum zoom, pixels, file size, pages/chapters

• Maximum pages: infinite - the caching system allows for unlimited pages.
• Maximum links: ~50. Anything higher takes 3+ seconds to load. Also depends on defining area tags in the xml or embedding in an swf page.
• Physical page dimensions: Flash has a pixel limitation of 2880x2880. A5 or A4 is recommended.
• Page file size: I tend to find 200-300kb is an acceptable limit. Any larger it will slow things down on a large full screen monitor and hog more bandwidth for your host and users.
• Maximum zoom level: It's recommended to not go much further than maxzoom=2
• Transparency: Keep to a minimum as this relies on the user's computer performance which for the most part is usually unknown.
• Pages in cache: 6-8 pages should be acceptable depending on overall file size and user's computer specifications. Less might be faster but hamper loading speed so test based on your files and user specs.

RECOMMENDED CLIENT-SIDE SPECIFICATIONS
- to be determined


KEY PERFORMANCE TWEAKS

Physical page size (width/height)
- Larger pages will slow performance
- Consider A5 pages instead of A4/Letter, this makes it easier to print too

Zooming
- Zooming in make more work for the user's graphics card to repaint the page, especially on higher resolution monitors and full screen. A compromise is to use the new "adaptive zoom" to have a quicker, smaller initial page and clicking to load a higher resolution zoomed page.

Transparency
- Avoid a lot of transparent layers

File size
- Keep file size low

Cache
- More pages stored in cache will use up more RAM but surely a small factor?

Dynamic page content
- Excess dynamic content can slow performance

File format
- swf pages load much slower than jpg pages

pdf2swf
- This was a helpful comment: http://megazine.mightypirates.de/forum/index.php/topic,587.msg2017.html#msg2017
adding the parameters to the pdf2swf conversion flattens the graphics and converts the page to a bitmap instead of vector shapes improving file size and calculations required during interactions.

Code: [Select]

-G -s bitmap -s jpegquality=85 -s zoom=100 -s subpixels=1Resolution
- Full screen slows performance
- Images should be compressed and flattened to 72dpi with cropped areas actually cropped, not hidden

Parameters / Customisation / Plugins
- Avoid necessary plugin use and over customisation from the default values/settings

Multi flipping
- when jumping across a few pages with the cool "multi-flipping" feature, it can obviously be slow as it's painting multiple pages, transparencies, and masks.

Initial fade in
- The opening fade effect can be slow as it requires multiple transparent layers of pages. This could be disabled.

Flipping speed
- With slower performing pages, the flippign speed could be increased to give the perception that it's faster.

[KuriousKook]

Hehe, I have to say I'm just glad your launching before me so I can learn from you.  Best of luck I'll let you know if I run across anything of help.

One question I have that relates to this, is there a way to determine at start up (or give guidelines for the user to determine) if their computer can handle it and point them to download .pdf options if not?

[Florian Nücke]

Nice list. Mind if I sticky that?

One point that's pretty much the culprit for a few of those points: the more actual screen space that has to be refreshed, the slower the performance. The actual bottleneck is the repainting of the display, which get's rather excessive when using large pages or zooming in quite a bit, because actual screen space (more pixels) have to be repainted. Of course, scaling also plays a part in that, because more transformations have to be applied for each pixel before it gets painted (well, of course it's still only one, assuming Flash does it right, which I'm assuming, but its still necessary to build the full transformation matrix once for each element).

I talked about it in this thread, but I tried reducing the default area that needs repainting when the pages don't fill the whole screen, and although I have no empirical proof, I think performance is a bit better. If you can, please feel free to give the current trunk version a run and see how it performs.

[Ecnassianer]

On some other flip viewers, there's a way to disable the transparency feature if you're not using any transparency in your book. In those viewers this provided a dramatic increase in performance. Is there an equivalent to this in Megazine?

[Florian Nücke]

This is probably done using the opaqueBackground property of Flash's display objects. At the moment I'm not using it, no.
I had a look into that a while ago, but the problem is, that apparently objects with an opaqueBackground don't work well
with masks (which are needed for the page flip animation).
I'll have another go at it, though. Might not be much, but maybe it'll improve performance somewhat.

[Ecnassianer]

BTW, to anyone looking for optimization tips. Upgrading to 2.0.7 and 2.0.8 both showed significant speed increases in my book. Unlike most software, Megazine actually gets faster as it ages!