Megazine 2.x slower than 1.x?

[enridp]

I've updated Megazine recently, I was using Megazine 1.x, and I'm noticing that my books now takes longer time to load.
I have commented this in another post, when myy preloader finish the books takes a few seconds to appear...
I have "solved" this just putting a message (loading pages...) that stay in the middle for 5 seconds... so the user knows the book will appear soon.
5 seconds was sufficient with Megazine 1.x, but now it takes around 9 seconds to appear!.
Is that normal?

Greets!
enrique.

[Florian Nücke]

The overall load time might be a little slower than in 1x, yes, because previously all functionality
was built into one fat SWF, now it's distributed over multiple smaller ones (the plugins), but that
also introduces some overhead. But I think it's worth the improved flexibility and extensibility

When using the preloader, in the latest version that also includes the progress of loading the
plugins etc, though, so if you use that it should not be necessary to add a custom message.

[enridp]

I'm using the latest version (2.05).
Maybe my preloader is wrong, can you show me an example for a full preloader?

[Florian Nücke]

The FLA used to generate is in the trunk, in the fla folder.

[enridp]

Yes! It works like a charm !
THANKS !!

[sitron]

i didn't check the source code to see how plugins are loaded, but if loading multiple small swfs is an issue, it could be a good idea to build a multi-plugins swf (you'd have to combine some of the predefined ant tasks to do that i guess). You would keep the dev flexibility of plugins and cut on the overhead of multiple loads.
But i don't know how difficult it would be to declare on one side which plugins should be used, and on the other which swf should be loaded...
tbc...

[Florian Nücke]

Well, the comfortable thing with using multiple SWFs is having the instance of the plugin ready to work with as soon as the SWF finishes loading.
What might work without any actual engine changes, though, would be to write a "compound" plugin, which just forwards all calls (register, initialize,
attribute handling and so on) to a fixed list of plugins that are compiled into that compound plugin... might try that out some time, to see how much
filesize that saves.