Bug: Book hard cover gets stuck when flipping

[kongo09]

I think I discovered a bug with 2.0.2 and 2.0.3. It is documented here http://bugs.mightypirates.de/issues/show/15

In essence, when I flip a "stiff" hard cover page with the keyboard or with the navigation buttons (but not by hand), it frequently gets stuck in the process. CPU then goes up to 100% for some seconds up to almost a minute at times, then comes down again and the flipping completes.

It doesn't happen when I flip by hand through dragging the page. Behaviour was observed on Linux, Mac and Windows in IE and Firefox.

Anyone else with a similar experience? Anyone with a fix?

[CraziestOzzy]

I have noted CPU running at 75% for a simple page turn on my PC, having read other people reporting high CPU consumption, I checked it myself. Different hardware/software combinations will obviously produce different results. It is a concern for me and I am diligent as to how many bells and whistles I include in the programming of my version of the Megazine book.
I am of the opinion that the engine is requiring another look by the creator to reduce loops, actuate memory dumps and unbounded ends that may cause what I personally consider to be excessive CPU bandwidth consumption.
This is my uneducated opinion and thus have probably offered no help.

[Florian Nücke]

The bug: I saw the ticket, but I couldn't reproduce it, so I decided to finish up this version before taking a closer look.

Regarding CPU load. The reason for that is the combination of two of the most resource-intensive effects there are: masks and transparency. And both are necessary. The masks are necessary for clipping the pages, to only show what should be possible, based on the current dragging position of the page. The alpha is necessary for the page highlight+shadow (although you could disable that -- looks horrible, though ). There are no loops that could be stripped down/early exited or so. For the technically inclined, the expensive stuff boils down to the updateMatrices() function in the Page class. What I haven't tried yet it to manually set the rotation and position (instead of using transformation matrices), but I doubt that'll make much of a difference.

If anyone has any concrete suggestions as to how to improve the performance, though, I'm listening

[CraziestOzzy]

Regarding CPU load...
If anyone has any concrete suggestions as to how to improve the performance, though, I'm listening

Seems you are aware of the unique requirements to your program. The OP (myself included) will have to take into account high CPU consumption and be aware that not all prospective clients viewing a book will have a computer up to the task. Limiting "bells and whistles" is the way to go...I might try and see if CPU consumption is reduced with a smaller book while turning a page and look into an option of turning off page fx for viewers with slow computers.
I myself have had no issue with the program with respect to CPU consumption and it is only through reading posts here that I have found there may be an issue worth being aware of when constructing a book for online use, albeit those with "slow" computers. Keep up the good work.

[kongo09]

Back to the original topic: How can we help to debug? I've seen this now on three different machines (Windows, Mac and Linux). I tried to do a screen snapshot, but even though the flipping page is visible on the screen when stuck, the screen snapshot doesn't show it. Maybe that's down to the way of how the graphics cards interact with flash? I have no clue?

Questions is: what can we do to help you fix this? What information can I provide? What analysis could I do?

[Florian Nücke]

Regarding the performance, I did some profiling, and the top-ranking slots were always occupied by Flash internal task, such as [render] and [pre-render] (see this site if you're interested in what that means). This means that I cannot really do all that much about it.
What I also realized, though, (pretty much by chance, actually) is that apparently the whole stage gets repainted every frame (if you have a debug-version of the player installed, there's this "Show redraw regions" option in the right click menu). Why? Well, it appears that Flash always updates every area where an element moves -- even if it's not visible at all. This, amusingly, is also true for masked objects and the masks themselves, making masks (performancewise) a pretty evil pitfall.
So, what I did for now is a little experiment: instead of applying the transformation matrices to the masks (and shadows/highlights) I "redraw" them every frame; apparently this redrawing itself is very cheap, only the actual rendering is where the main CPU consumption takes place. So now only the minimum necessary area gets actually repainted when dragging a page.
A downside of this is, that the banding of the shadows and highlights is now a little more apparent, because additional stripes pop up or vanish as the size of the gradient changes (wheres before I could just scale the whole gradient, also making the banding less apparent when the gradient was smaller, i.e. the page had not been dragged very far). But if the alpha isn't set too high this is barely noticeable, especially when just flipping through, and not dragging manually.
If you're interested, have a look at the current SVN revision and tell me if you notice any difference. I can't prove it, because I haven't found a way of creating a constant CPU load... but I think in average the load is lower than before. At least when the pages don't take up the whole screen space. As soon as they do everything has to be repainted anyway...


Regarding the bug: could you post a minimalistic book definition (megazine.mz3) that reproduces that problem and describe the exact way of reproducing the bug?
Also, please let me know what hardware the machines had (at least an approximate, i.e. 1ghz, 2ghz, 3ghz) because it could well be I just don't notice it because my machine is too fast (well, it's not that new anymore, but anyways). I'll try it on an equivalent machine (and if I have to use the stoneage machines at university ). I don't think anything else is much of a factor (Flash Player version, browser...), but if you have it at hand, please let me know that, too.

[kongo09]

I'll send you some files in a private message.

Machines are otherwise powerful Core2Duo with 2GB RAM (and more) and new Apple Powerbooks.

[Florian Nücke]

Got it, will have a look at it. Thanks

[Florian Nücke]

I've also sent you a mail, but to let everyone else know, too:

This problem was caused by a very large SWF that was loaded into the page, causing Flash to slow down to a crawl when the page was standing perpendicular to the book itself (i.e. the page was not much more than a line).

The solution is to either not use such huge SWFs (500KB), or use the page@buffer attribute (or the img@rasterize one, although that makes using such a huge SWF kinda meaningless in the first place).