In our javaScript game we are having a problem where "touchmove" events are slow and "janky" until an orientation change at which point they become smooth again.
The slowness returns when the game does a lot of work like loading a level.
Here is a video that show the slow touch move in action, and the orientation change which fixes the issue.
https://youtu.be/7rSqkJuOQjc
The following warning does appear in the log
Handling of 'touchmove' input event was delayed for 141 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responive.
However, the slow events persist well after the game has stopped doing heavy lifting like loading a level and building sprites.
I cannot use passive handlers in any case becuase panning the map must preventDefault to stop the interface scrolling as well.
I assume the slowness is related to touch events as I have measured how often the touch handlers are called and they seem strange.
Will receive 5-10 events in a row in under ~20ms, then there will be one that is about 150-200ms, then another batch of fast events, and another slow one.
After the orientation change, all events are received in under 20ms
I have also measured my responses from requestAnimationFrame and they seem to be a fairly solid 16.8ms
For those intrested you can see the problem yourself at https://blight.ironhelmet.com
The problems occur in Chrome and Cordova, both native and using Crosswalk.
The problems do not occur on Safari on iOS or any tested Desktop browser.
I would like to know if anybody else had this problem and how I might go about fixing it.
Is possible to force an "orientation change" or whatever happens during an orientation change, using javaScript?
The hardware renderer was not kicking in, and the slow software rendering was slowing event processing. (drawing pixels from one canvas to another)
After an orientation change, it seems that the garbage collector cleaned up unused canvases which enabled the hardware renderer to kick in.
Related
I'm trying to use the output of systrace to detect janky scrolling during automated tests: I want to notice it early, without having to sit there watching.
I spent some time trying to fathom the trace, and found this ebook very helpful: https://www.safaribooksonline.com/library/view/high-performance-android/9781491913994/ch04.html
The most promising hypothesis was checking whether VSYNC-sf ever stopped ticking on phones displaying VSYNC-sf.
On other machines, SurfaceFlinger seems to be started by either HW_SYNC_0 or VSYNC (sometimes one or both of those VSYNCs stop) but SurfaceFlinger also seems to be involved with VsyncOn, which sometimes appears to keep track of whether there are activity buffers outstanding, and sometimes whether there are input events that need delivering. Confusingly, sometimes input events are delivered during half-second pauses when there's no surface flinger activity, no application drawing, and when even the VSYNC and HW_VSYNC signals decide to pause.
Does anyone know what's going on there?
Should I simply expect to see Surface Flinger always busy - not alternately busy and idle with each tick - and always aligned with one or other of the VSYNCs?
I also sometimes see SurfaceFlinger taking longer than a tick to complete its processing - is that the application's fault for having a very complicated display, or is it just something that happens because some queue isn't empty enough?
I'd prefer to miss a possible jank than claim to have found one which isn't there.
Thanks!
Testing Display Performance Lists how to use the new framestats command from dumpsys to get this type of information. It will provide information on what frames you've missed, and how many of them you've missed.
It's also worth noting that SurfaceFlinger isn't always busy. It's only active when part of the screen needs to be updated. If nothing on the screen needs updating, then no new rendering occurs, and such, SurfaceFlinger should be idle.
You can get a bigger-picture view of the Android rendering pipeline with the Rendering Performance 101 video from Android Performance Patterns.
I have been working on a game where speed is required to score well, in the game the user is clicking on objects and using them with other objects which are held in a gridView that's being controlled by an imageAdapter. I have noticed that when I click quite fast some clicks don't register, I have cleaned up the code running when the user clicks but that doesn't seem to be the problem since I tested it just highlighting objects and not running code when clicked and it was just as slow. So is there a way to speed up the click detection, or would this be limited by the speed of the device its self, I have been testing on an htc one m8.
Return as soon as possible from the handler and run the UI update code in background with 'runOnUiThread()'.
Notice that changing view status MUST be done in the UI thread or the Android runtime will throw an exception. You can work complex calculations in background 'AsyncTask' and call 'runOnUiThread()' from within them whenever you want to update UI components.
As far as I know, there is no way to do such think. It depends on the speed of your hardware. But what you can do is to use the onTouch listener. In this way you listen only after one action(when it is pressed). for onClick it is registered 2 actions(when u press the button and when u release the button). In this way maybe you could do it faster.
You can also try this:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
I have an app developed with Sencha Touch and phonegap. At one point, it downloads data from a server and, once it has received a successful response, it displays the next screen. I found, when bundling it up as an iOS app, that it would transition to that next screen, but not display anything, reporting low memory. So I simplified the layout of that next screen (the DOM structure was pretty complex) and it now works on the iOS simulators and on my iPhone.
However, in Android, I can see from the output of my console.log statements that it successfully retrieves the data and fires an event to display the next screen. It then sits around for ages before it displays that screen, even though my console.log statements show that the 'painted' event of that screen has been fired.
Eventually, the screen does show up, but all the controls on the screen are unresponsive to touch. Is it likely that I need to simplify the structure of that screen still further? As the iOS version received a low memory warning before I simplified the page structure, I suspect the Android version may have a similar problem, but I don't know how to monitor memory usage. In the Android version, shortly before the screen does eventually display I see the following in logcat:
UpdateFrameCache: pending style recalc, ignoring
And on the screen which is unresponsive, when I tap some (but not all) of the unresponsive controls, I see:
Got ACTION_DOWN but still waiting on stale event. Catching up.
Eventually, the app will just close itself, with:
Fatal signal 11 (SIGSEGV) at 0xbbbadbeef (code = 1)
Any help gratefully received.
If you perform intensive computations in the UI thread, it might explain why it takes so long.
Try using AsyncTask or a Service if you have some backgorund computations to do. Once they are done, update the interface in the UI thread.
Gordak
I am trying to make a game on mobile with adobe air. Everything went smoothly 'till I encounter problems with mouse click event. I experience very slow response on button/movie clip when adding mouse click event listener to mimic tap/touch event on mobile. The delay time after player's finger tap the button/movie clip till the execution is 1-2 seconds (really annoying really).
So I wonder I should change to touch_tap event instead of mouse click event and hope things change for good. Unfortunately it doesn't really show any difference.
I played a lot of games on android (and I think they are made by flash) and I can not understand why their tap event and response time is unbelievably fast (almost instant after the my touch/tap on the button/movieclip). Anyone could help me shed light on this?
I don't think handling TouchEvent make THAT much difference since Flex framework currently deals with MouseEvents and there's basically no such delay.
What it reminds me though is a rare bug I met in some previous versions of FlashPlayer and (desktop) AIR where mouse and keyboard events were delayed up to several minutes(!) on some specific hardware at some specific views (I mean some set of objects on the screen). The important moment here is to say that current framerate was high and constant(!), so it's not a general performance issue. Event though Adobe says it was fixed, I'm not really sure as they didn't show any certainty about it.
So try to check if framerate is OK, if it is — nasty runtime bug... and you should try to play around with display list, blend modes, cache-as-bitmaps (if presents).
Make sure you disable doubleClick. Sometimes this is the reason for a delayed response... guess doubleClick-time for touchinputs is even longer than on desktop...
I'm doing a game with game loop and active rendering (using SurfaceView and SurfaceHolder.Callback).
I'm wondering how to make that work together with timed events and touch event management.
The timed events are like each xx ms something happens, each yy ms something different happens.
Touch management is update game and screen when down, up, and move.
I have made a few tries, but it looks somehow awkward and the game isnt performing very well..
On one side I have a classic game loop (in separate thread):
while running update, render, draw, sleep a bit
Now I didn't know well how to make this work with timer loops. I used handler approach - make classes which extend handler, do what they have to do in handleMessage, and call then themselves with sendMessageDelayed.
They just update game state. The rendering of the resulting changes would be done in the gameLoop.
This approach needs synchronization for update of gameloop not intefering with update of the timers.
And - besides of this I need to handle touch events - down, up, and move!
My approach here was, like in the timers, just update game state, and leave it to the loop to handle and display correctly.
I don't know if I'm maybe on the completly wrong path, noob to Androd, and made it just like i thought "could work".
For example I'm not sure if its necessary to make a game loop in a separate thread. I thought it was, to show the results of touch handling (move) according to certain framerate.
On the other side I could leave the loop and just tell to draw after each timer update, and after each touch handling, but this doesnt work well either.
The question is what's the general approach for this kind of game? (timed loops / touch event (move) which has to render to screen continuosly).
Thanks in advance.
Have you read Using Input Pipelines In Your Android Game? It presents a solution to your problem for handling input.