Support for slow computers

[Gil]

We are currently running a Megazine based application on a relatively slow computer (Atom 270).
Most things run well, however the slow response exposes certain things that on a regular setup the user cannot see.

One of those is when flipping a page for a fraction of a second (although quite visible) the user sees another page while the flipping effect starts. I guess it's all due to the slow refresh rate of the computer. Can you offer a solution?

Thanks
Gil

[Florian Nücke]

Could you do a real short screencap of that effect, so that I can see it? Would help a lot to know which page
gets shown (it's probably a lacking update after updating visibility somewhere, but the where is the problem )

[Gil]

Hi Florian

Well, one issue that can be easily reproduced on modern computers is the "sticky cursor": double click a book's edge (middle, not top or bottom) and you should see the page starts to follow the mouse regardless of a click (if it doesn't happen then try a few more times). I have managed to bypass the problem by adding a custom check on the following function:

DragHandler.as
private function handleMouseMovement(e:Event):void {
...
if (inCorner || draggedPage.state
                        == Constants.PAGE_STATE_DRAGGING_USER && megazine.flipState != "megazine_flip_state_ready")

[Florian Nücke]

Hm, that change makes it impossible to start a manual drag (keeping the lmb pressed)
while a page is turning though, so I don't really want to use it. As you say it happens
when clicking (are you 100% sure you're not moving the mouse even a little?) the call
to the function must be triggered due to a state change... could you please try this:
Add a variable to the DragHandler class:

Code: (actionscript3)

private var mouseMoveTimeout:uint;

And then adjust the changeState function:

Code: (actionscript3)

// replace
setTimeout(handleMouseMovement, 100, null);
// with
clearTimeout(mouseMoveTimeout);
mouseMoveTimeout = setTimeout(handleMouseMovement, 100, null);

I tried a lot, but I can't reproduce it, so I'm flying blind here, though.

[Gil]

Well, I can testify that my change allows a manual drag just as always.
The weird thing is that when I run one of the basic demos the issue doesn't exist.

But getting back to the original problem. This is what I see (even now):
If I click the middle of the edge of a page to flip it. The page auto-turns. Works wonderfully.
But if I click a button which triggers a gotoNextPage, for example, the following thing happens:
1) Let's assume I am at page 2 going to page 4 (single page flip).
2) Before I call the function I see page 1 on the left side as I should.
3) When I call the function I see page 3 appearing for a very brief moment.
4) The page flipping effect starts and page 3 disappears to reveal page 1 once again.
5) The page flipping effect is over and page 1 is now replaced by page 3 as it should.

The thing to notice: if I could trigger the page flipping effect externally EXACTLY like clicking the page itself then the problem would disappear altogether. However, the process seems to be very complicated, since you are relying heavily on mouse location throughout several classes and interact between mouse down and up events.

I think it would be a very good feature to add an auto-flip function (not the way gotopage currently works).

[Gil]

I have attached a screen recording of the problem.
You should see the blinking effect after the 3rd and 5th time I click the left arrow (instead of the page). The movie was recorded on a strong system. On a slower system the effect is more evident and severe.

[Gil]

Another VERY important note: I am using movieclips with dynamic content on the pages, so definitely it is taking its toll on the system resources.

[Gil]

Hi Florian

I haven't received any reply to this issue. Did you get to look at it?

Thanks
g

[Florian Nücke]

Hi,

sorry for the late reply, I hadn't forgotten, though. Weird effect.
I'll definitely have another look at this over the next days. And will
try to get running Flash on my not so fast laptop (which is currently
running Linux... so it should be even slower, if the Adobe flamers
are to be believed )