Hello everyone,
I was doing some tests and it seems that the “touch moved” event seems to be firing faster than in the other platform. I mean, dragging the finger on the screen for similar time/distance, it seems that I am receiving a lot more events.
I checked and I’m only registering a single event listener. Is this normal behavior or am I doing something wrong ? Is there a way for me to control the “fire rate” of the event ?
We’re just passing the touch input events from WP8 to Lua as-is. We do the same on other platforms as well. It is noticeably faster compared to Android. I always assumed that WP8 was just more efficient in handling touch input events than other platforms.
Is it a problem for you?
If so, then what are the negative side-effects?
In some games that we use the moved event as a control to some in-game object we suffer a noticeable performance hit. I am still testing, trying to find the cause, if this performance loss comes from doing something that comes from simply calling the same code more often on windows phone or if it comes from some part of the code that is more expensive on windows phone.
I’ll post more information when I’ve done some more testing (and probably more questions too).
You can definitely get multiple touch events per frame.
So, it would definitely be more efficient to only move or display objects during the “enterFrame” in this case.
Although, before going there, I’d recommend that you check if you’re doing a display.newText() or if you’re updating text when a touch event occurs. Text bitmap generation on WP8 is extremely extremely expensive. Also, a lot of print() functions *might* slow things down since we have to convert Lua’s UTF-8 strings to UTF-16 before logging it, which is only a noticeable performance hit when you’re printing a lot of strings at once. Although, the version you’re using is already pretty optimized when it comes to printing to the log.
I noticed a few things firing up multiple times and then I realize there is an up/down event which I need to use as well. Could this be related? IE move is combining with up and down event, casing your function to operate quicker?. I for one am glad id the touch response is quicker as this might make audio latency form buttons better than the horribly slow Android system
I did some tests and seems that the performance loss is a combination of a few different causes. On some parts I’m moving images around based on the touch moved events, and since it fires faster, it was causing the device to lag. Throwing away some events seemed to improve performance.
There was another case where we used the touch event with the physics engine (using the “touch joints”). In this case, throwing away event didn’t help, but delaying some of event (for example using timer.performWithDelay) helped. Now I’m not sure if this is because of the faster touch moved events or a difference in the behavior of the physics engine.
@Rob, somewhat off topic but the audio delay problem in Android (which is quite annoying) is related to their implementation of the openAL interface, which the audio library. In Android devices I use the old media api to work around this delay. You lose some nice features (pitch control for instance) but there is practically no delay anymore.
*Edit: Forgot to mention. We already removed calls to the display.newText, using bitmap fonts instead and wasn’t printing during this testing.
I find that moving shapes and images doesn’t have much of an impact on performance… unless of course your are creating new shapes or loading images on each touch, which would slaughter the performance.
Now, updating a physics object definitely will have a performance impact.
For best performance, I recommend that you do not update your objects’ positions immediately via touch events. Instead, store the last received touch position(s) to variables and then update your object positions on the next “enterFrame” event. This will provide the best performance. Also, there is no point in updating an object’s position multiple times between frames because the end-user will never see those movements. End-users can only see the final position that was drawn on the next frame.
I’m also pretty sure that Android and iOS deliver multiple touch events between frames as well. So, the above should yield performance improvements on those platforms as well. I also know for a fact that Android definitely queues several touch events between frames, which has caused havoc with our Corona widget library developer, but the biggest problem Android has is touch latency. Interesting enough, WP8 has the least latency when it comes to touch. Makes things interesting, eh?
Hey Joshoua,
I was reviewing my code after your post and got a couple questions. One part that is lagging for me is setting the rotation of a display object during the touch moved event.
local handleX, handleY = handle.parent:localToContent(handle.x,handle.y) local angle = math.fmod(handle.startRotation - (math.atan2(event.x-handleX,event.y-handleY) - handle.touchAngle)\*180/math.pi,360) -- normalize the rotation at (-180,180] if angle \<= 0 then angle = angle + 360 end if angle \> 180 then angle = angle - 360 end -- bound the rotation if angle \<= -85 then angle = -85 elseif angle \>= 85 then angle = 85 end handle.rotation = angle
This shouldn’t have much impact in performance right ?
Regarding the position of physical objects, we found that indeed setting its position was quite costly, so what we do now is use the “touch joint” element and do a setTarget during the move event. Is this function also expensive, performance wise, or should it be fine ?
This is all stuff we already do on other platforms, but we are getting a lower performance on windows phones. Do you see a difference in performance between platforms, or could this be mostly because of the devices we are using for tests ?
Hey Joshua, just posting a quick a update.
I did some tests and moved some code around, trying to minimize the amount of movements of display objects and saw some performance improvements. But I think the real problem is the device that I am using to test. As soon as I dropped the fps to 30 the game became a lot smoother, so it seems it just didn’t have enough processing to render my game at 60 fps.
Thanks for tips about performance! I’ll see how we can use it to improve our other games as well.
Another thing I should bring up is that WP8 XAML Silverlight based apps have performance issues in general. This is because there is only 1 Direct3D rendering context that must be shared between Corona and Microsoft’s XAML UI framework… and they are in direct competition for dominance of that one rendering resource. Other 3rd party SDKs, such as Unity, have this same issue (search their forums; a lot of them are getting less than 30 FPS). Unfortunately, if you want to use WP8’s native UI such as ad banners, text boxes, and other UI features, then you have no choice but to make it a Silverlight app. (Versus a pure C++ Direct3D app would not have this performance issue, but then you lose native UI and .NET support.)
On my Lumia 920, my framerate with a busy physics based app usually hovers around 45 FPS. Without physics, I get just over 50 FPS. I’ve also concluded that getting 60 FPS from a Silverlight based app on a Lumia 920 is impossible because the Direct3D rendering thread on WP8 (which is out of our control) has a nasty habit of rendering late every 4th frame. (Note that Microsoft considers my Lumia 920 a low-end device, so, the framerate we squeezed out of it might be considered good for what it is.)
Now, other Corona developers I’ve worked with have reported to me that the framerate is actually pretty good now. I’ve spent a considerable amount of time with a Corona developer named @whammy (one of our first beta developers) in squeezing out as much performance as we could get from a low-end WP8 device. He said he saw a noticeable improvement. Just out of interest, have your tried testing your app on a newer quad-core WP8 device? You should see a better framerate compared to what I’ve posted in my paragraph above.
One more thing. Setting up your app for 60 FPS *might* have a negative performance impact if you display native UI. The reason is because when you put Corona in 60 FPS mode, then we’ve set up our code internally to *dominate* the Direct3D thread to ensure that we can render as many frames as possible (otherwise Microsoft’s XAML framework will dominate it and prevent Corona from rendering in time). Some native UI, such as the WebBrowser control, are not affected. But a TextBox control with the native keyboard displayed will have cause a huge framerate impact and both Corona and the native UI will stutter for it. If your app tends to display a lot of native UI, then you should set up your app for 30 FPS, because that puts Corona in a mode to make it more native UI friendly. Meaning, we yield the Direct3D thread to the native UI and wait for it to give us that Direct3D resource when it’s ready. Unfortunately, this make framerates higher than 30 FPS impossible on our end. There is no solution to make it work both ways, so, this is the compromise we had to make. That said, displaying native UI in 60 FPS mode will probably look okay if your app is displaying a static/non-animated background, because then the dip in the framerate won’t be noticeable to the end-user.
One more thing. You can use the following Lua script to measure the average framerate per second. Would you mind running it on your app? I’d be interested in the results.
local lastEnterFrameTime = nil local durationCollectionSize = display.fps local durationCollectionIndex = 1 local durationCollection = {} for index = 1, durationCollectionSize do durationCollection[index] = 0 end local function onEnterFrame(event) local currentTime = system.getTimer() -- If this is the first frame, then fetch the current time and exit out. if (lastEnterFrameTime == nil) then lastEnterFrameTime = currentTime return end -- Store the duration since the last frame. durationCollection[durationCollectionIndex] = currentTime - lastEnterFrameTime lastEnterFrameTime = currentTime -- Do not continue if we have more durations to collection before averaging below. if (durationCollectionIndex \< durationCollectionSize) then durationCollectionIndex = durationCollectionIndex + 1 return end -- Average the collected durations and print it to the log. local averageDuration = 0 for index = 1, durationCollectionSize do averageDuration = averageDuration + durationCollection[index] end averageDuration = averageDuration / durationCollectionSize local averageFps = 1000 / averageDuration print("Average FPS = " .. tostring(averageFps) .. ", Average Duration = " .. tostring(averageDuration)) -- Reset data collection. durationCollectionIndex = 1 end Runtime:addEventListener("enterFrame", onEnterFrame)Tapps. (RE audio latency and using old API) My main audio apps need pitch so thats why I need to use the new one. Testing now and so far (testing my laser harp app) its pretty nippy. Theres a tiny delay but its actually playable. Ill stick a music sequencer on it next. Im looking into other Windows Apis. Its rather complicated but If I can get to access the buffers or make my own to access effects and sub masters etc/ I personally would love to record the apps audio. This is another subject though so I wont derail this one any longer 
We’re just passing the touch input events from WP8 to Lua as-is. We do the same on other platforms as well. It is noticeably faster compared to Android. I always assumed that WP8 was just more efficient in handling touch input events than other platforms.
Is it a problem for you?
If so, then what are the negative side-effects?
In some games that we use the moved event as a control to some in-game object we suffer a noticeable performance hit. I am still testing, trying to find the cause, if this performance loss comes from doing something that comes from simply calling the same code more often on windows phone or if it comes from some part of the code that is more expensive on windows phone.
I’ll post more information when I’ve done some more testing (and probably more questions too).
You can definitely get multiple touch events per frame.
So, it would definitely be more efficient to only move or display objects during the “enterFrame” in this case.
Although, before going there, I’d recommend that you check if you’re doing a display.newText() or if you’re updating text when a touch event occurs. Text bitmap generation on WP8 is extremely extremely expensive. Also, a lot of print() functions *might* slow things down since we have to convert Lua’s UTF-8 strings to UTF-16 before logging it, which is only a noticeable performance hit when you’re printing a lot of strings at once. Although, the version you’re using is already pretty optimized when it comes to printing to the log.
I noticed a few things firing up multiple times and then I realize there is an up/down event which I need to use as well. Could this be related? IE move is combining with up and down event, casing your function to operate quicker?. I for one am glad id the touch response is quicker as this might make audio latency form buttons better than the horribly slow Android system
I did some tests and seems that the performance loss is a combination of a few different causes. On some parts I’m moving images around based on the touch moved events, and since it fires faster, it was causing the device to lag. Throwing away some events seemed to improve performance.
There was another case where we used the touch event with the physics engine (using the “touch joints”). In this case, throwing away event didn’t help, but delaying some of event (for example using timer.performWithDelay) helped. Now I’m not sure if this is because of the faster touch moved events or a difference in the behavior of the physics engine.
@Rob, somewhat off topic but the audio delay problem in Android (which is quite annoying) is related to their implementation of the openAL interface, which the audio library. In Android devices I use the old media api to work around this delay. You lose some nice features (pitch control for instance) but there is practically no delay anymore.
*Edit: Forgot to mention. We already removed calls to the display.newText, using bitmap fonts instead and wasn’t printing during this testing.
I find that moving shapes and images doesn’t have much of an impact on performance… unless of course your are creating new shapes or loading images on each touch, which would slaughter the performance.
Now, updating a physics object definitely will have a performance impact.
For best performance, I recommend that you do not update your objects’ positions immediately via touch events. Instead, store the last received touch position(s) to variables and then update your object positions on the next “enterFrame” event. This will provide the best performance. Also, there is no point in updating an object’s position multiple times between frames because the end-user will never see those movements. End-users can only see the final position that was drawn on the next frame.
I’m also pretty sure that Android and iOS deliver multiple touch events between frames as well. So, the above should yield performance improvements on those platforms as well. I also know for a fact that Android definitely queues several touch events between frames, which has caused havoc with our Corona widget library developer, but the biggest problem Android has is touch latency. Interesting enough, WP8 has the least latency when it comes to touch. Makes things interesting, eh?
Hey Joshoua,
I was reviewing my code after your post and got a couple questions. One part that is lagging for me is setting the rotation of a display object during the touch moved event.
local handleX, handleY = handle.parent:localToContent(handle.x,handle.y) local angle = math.fmod(handle.startRotation - (math.atan2(event.x-handleX,event.y-handleY) - handle.touchAngle)\*180/math.pi,360) -- normalize the rotation at (-180,180] if angle \<= 0 then angle = angle + 360 end if angle \> 180 then angle = angle - 360 end -- bound the rotation if angle \<= -85 then angle = -85 elseif angle \>= 85 then angle = 85 end handle.rotation = angle
This shouldn’t have much impact in performance right ?
Regarding the position of physical objects, we found that indeed setting its position was quite costly, so what we do now is use the “touch joint” element and do a setTarget during the move event. Is this function also expensive, performance wise, or should it be fine ?
This is all stuff we already do on other platforms, but we are getting a lower performance on windows phones. Do you see a difference in performance between platforms, or could this be mostly because of the devices we are using for tests ?
Hey Joshua, just posting a quick a update.
I did some tests and moved some code around, trying to minimize the amount of movements of display objects and saw some performance improvements. But I think the real problem is the device that I am using to test. As soon as I dropped the fps to 30 the game became a lot smoother, so it seems it just didn’t have enough processing to render my game at 60 fps.
Thanks for tips about performance! I’ll see how we can use it to improve our other games as well.