iPad Safari Rapid Tap Issue

[Glenn Wilson]

As an aside I have not been able to login or register at http://jangaroo.myjetbrains.com/youtrack/dashboard

I either get "This user is banned" or "The administration side of YouTrack is currently under maintenance.

Please contact your administrator for details." when I try.

On one particular site:

http://streathambrixtonchess.blogspot.com/2013/03/random-rook-endings-vi.html

Which has multiple instances (I don't know if that is a factor) of ChessFlash, rapidly clicking the VCR controls (or elsewhere on the board) results in Safari on the iPad crashing.  I can't make this happen in Chrome on my Desktop or Android device...

Not sure if this is a framework or application issue but any advice would be appreciated.

Thanks,

Glenn

[Frank]

On Monday, March 18, 2013 1:44:57 PM UTC+1, Glenn Wilson wrote:

As an aside I have not been able to login or register at http://jangaroo.myjetbrains.com/youtrack/dashboard

I either get "This user is banned" or "The administration side of YouTrack is currently under maintenance.

Please contact your administrator for details." when I try.

Well, you just did! ;-)
And I did, too, asking Jetbrains YouTrack support why our "plan" got reset to only 10 users. Because that is the reason you have been "banned" and I currently cannot "unban" you...
So please stand by, the Jetbrains guys are usually quite quick to help!

Greetings
-Frank-

[Glenn Wilson]

I have created a post:

http://www.glennwilsonchess.com/2013/03/stress-test-1.html

With 14 instances of ChessFlash.  The original where I noticed this issue had 7.
In this new page, the issue is evident very quickly even without rapidly clicking.

I am using an iPad Wi-Fi 16GB 3rd generation.

Also just checked with my iPod Touch 4th Gen.  It can't load either of these pages (Safari crashes) but can load and run a page with two instances  with no apparent issues.

Is this likely a memory issue? Threading?  Should multiple instances on the same page be expected to work (if memory is sufficient)?

Thanks,

Glenn

[Glenn Wilson]

Just looked at Settings>General>About>Diagnostics&Usage>Diagnostics&Usage Data

and I have LowMemory crash reports on both devices.  So I suppose that is the issue.

Any thoughts on graceful degradation instead of crashing?

Thanks,

Glenn

[Frank]

On Monday, March 18, 2013 3:52:48 PM UTC+1, Glenn Wilson wrote:

Just looked at Settings>General>About>Diagnostics&Usage>Diagnostics&Usage Data

and I have LowMemory crash reports on both devices.  So I suppose that is the issue.

Any thoughts on graceful degradation instead of crashing?

As far as I know, it is not possible to react on low memory from JavaScript.

I'm just releasing jangaroo-libs 1.0.2 with the fixes that allow you to use "cacheAsBitmap" mode on the whole stage (interactivity of buttons now works). I guess the many canvas elements are what cause the extreme memory consumption. So I'd suggest you wait a couple of hours, then rebuild chessflash with JooFlash 1.0.2 and stage.cacheAsBitmap = true and try again.

Greetings
-Frank-

[Frank]

On Monday, March 18, 2013 6:02:16 PM UTC+1, Frank wrote:

I'm just releasing jangaroo-libs 1.0.2 with the fixes that allow you to use "cacheAsBitmap" mode on the whole stage (interactivity of buttons now works). I guess the many canvas elements are what cause the extreme memory consumption. So I'd suggest you wait a couple of hours, then rebuild chessflash with JooFlash 1.0.2 and stage.cacheAsBitmap = true and try again.

The release is now done and again you have to wait until Maven Central is sync'ed. You can check for sub-directory "1.0.2" to appear here:
http://repo1.maven.org/maven2/net/jangaroo/jooflash/

I was hoping to find another bug that still the layout of Open Flash Charts is garbled in non-bitmap-mode and that there is too much CPU usage when nothing changes on the stage.
But I thought you need something to try out now while I keep on debugging...

Greetings
-Frank-

[Glenn Wilson]

Cool. 

I was playing around with this more on the iPad and using the System Status app to look at memory usage and it seems  (some speculation on my part here) the crash is caused by memory consumption that spikes when the UI is resized.   Some rapid/double taps are interpreted to resize the UI and that seems to be the issue.  If I just pinch and zoom some it will also happen.  

But if I pinch and zoom, wait a bit and do some more so garbage collection can run (?) it does not seem to crash for one page I am testing.  In that scenario I can see memory use go up but then come back down in a bit....

[Frank]

Yeah, that could explain it.
Some background: Recently, I introduced Flash resize events to JooFlash. Upon resize, everything will be redrawn. When you enlarge, all canvas elements have to grow. Unfortunately, HTML canvas elements are not meant to change their size: whenever you resize them (even by a single pixel), their content gets wiped, so I guess the whole canvas bitmap is re-allocated. That would explain the memory consumption.
What can we do about it? First, we'd probably have to check whether it is an actual resize or just a zoom. Then, we could buffer resize event if they occur too frequently, so that the UI reacts "lazily".

But the most important thing is to use less memory in the first place, and the "cacheAsBitmap" strategy should be the way to go for that.

[Glenn Wilson]

I have played around with 1.0.2 some and clearly there has been some real progress.  And I appreciate the fast turnaround!

On my Windows desktop with Firefox or Chrome it looks and acts great!  I had started checking out memory use earlier today with Task Manager and 1.0.2 starts with a little more memory use but it  grows very little as I exercise the app compared with 0.9.9 where it can grow pretty fast just flipping the board.  Does not appear to matter if stage.cacheAsBitMap is set or not.

With stage.cacheAsBitMap it looks good on iPad/Android (Chrome on Android). But frequently (I think the cacheAsBitmap setting does not matter) one click of the play button results in two moves being made.  As if two click events were sent and processed.  That does not happen on the Desktop.  

Also, on the iPad stress test with 7 instances only two seem to get fully initialized and show the chess board.

Build 0.9.9/0.9.9 Stress Tests:

http://www.glennwilsonchess.com/2013/03/stress-test-1.html

http://www.glennwilsonchess.com/2013/03/stress-test-2.html

1.0.2 / 1.0.1 Stress Tests:

http://www.glennwilsonchess.com/2013/03/stress-test-1a.html

http://www.glennwilsonchess.com/2013/03/stress-test-2a.html

Let me know if I publishing something else / more for you to see would be helpful.  I may take a crack at debugging the event issue but the last time I tried stepping through the event processing code I lost my way. :-)
Thanks,

Glenn

[Frank]

We had similar issues with the Jangaroo version of Open Flash Chart on the iPad when showing several charts on one page.

The underlying problem is that in the current setup, each JooFlash "plugin" is a heavy-weight iframe with all the JooFlash code (850k of JavaScript!) in it, over and over again!
This would be comparable to the FlashPlayer plugin being installed many times, with no runtime code sharing whatsoever.
To get this working reliably on a device with low resources (CPU, memory), we need to let one JooFlash render several stages. In theory, JooFlash is already capable of doing so (this part of the code is inspired by DartFlash, thanks guys!), but I never tried it out. You would only load JooFlash once, and then create several stages instead of one. Note that these can be anywhere on the page, they are <div>s referenced by their id. Putting a JooFlash application into an iframe is not necessary, it is only more convenient to completely separate JavaScript and CSS from the main page. If you let JooFlash render everything into one canvas (cacheAsBitmap), there is not much CSS involved, so for a single application like ChessFlash, it should work. However, you have to be careful with static variables / singletons, which in the current implementation would be shared between stages.

If that sounds too experimental to you, the pragmatic solution is to split multiple views to multiple pages for the mobile / iPad version of the Web site.

Greetings
-Frank-

[Frank]

Well I just tried to use multiple stages with ChessFlash on one HTML page, and after two small fixed, it actually seems to work!
Because I don't want to release jangaroo-libs again right now, and the fix is in the bootstrap class "Run", you can copy the latest version of that class from Github:
https://github.com/CoreMedia/jangaroo-libs/blob/e1b20b1c13b82fbf4a424333f25597f3f90cf05c/jooflash/src/main/joo/joo/flash/Run.as
To avoid clashes with joo.flash.Run that comes with JooFlash, you should move the copy to another package (e.g. "chessflash.joo.flash") and then use your updated version of "Run" to start ChessFlash (I didn't test that part, but it should work).
It is then possible to load jangaroo-application-all.js on the main page and start the application multiple times with different stage ids and different params:

<div id="stage1">Loading stage 1...</div>
<div id="stage2">Loading stage 2...</div>
<script type="text/javascript" src="joo/jangaroo-application-all.js"></script>
<script>
  joo.classLoader.run("chessflash.joo.flash.Run", "stage1", "chessflash.Inline400", { ... });
  joo.classLoader.run("chessflash.joo.flash.Run", "stage2", "chessflash.Inline400", { ... });
</script>

Have fun,

-Frank-

[Glenn Wilson]

Cool.  I'll take a look at that. Is that compatible with 1.0.2 libs only?

I've just checked in some changes in ChessFlash to reduce object creation to reduce memory use and changed "char" variable names to "achar" to avoid the JS conflict.

[Frank]

On Tuesday, March 19, 2013 12:20:08 PM UTC+1, Glenn Wilson wrote:

Cool.  I'll take a look at that. Is that compatible with 1.0.2 libs only?

I only tried it with 1.0.2. There may be changes in joo.flash.Run between 0.9.9 and 1.0.2 that would have to be taken into account.
Do you still have any issues with 1.0.2 that you did not have with 0.9.9?
 

I've just checked in some changes in ChessFlash to reduce object creation to reduce memory use and changed "char" variable names to "achar" to avoid the JS conflict.

Great, that should get me rid of my local changes to make it Jangaroo-3-compatible!

Greetings
-Frank-

[Glenn Wilson]

Initial tests with multiple stages (running local on windows) seems to work fine for 2 stages but at 3 or 4 stages the 3rd and 4th instances of ChessFlash render correctly but are not responsive to mouse clicks at all.  However the last stage (in order of the div in the html) will get keyboard events.  With 3 or more sometimes one or both of the first 2 stop responding to mouse clicks.  Especially if I use the keyboard with 3 or 4 stages the first two often stop responding to mouse events.

In the debugger I can see that Stage.handleMouseEvent is called on MouseEvents but in the non-responsive Stages the variable "target" is null which seems to prevent any further processing...