Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Touch moved event firing too quickly ?
Started by Tapps - enterprise Sep 24 2014 12:09 PM

34 replies to this topic
[TOPIC CONTROLS]
Page 1 of 2 1 2
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

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 ?



[TOPIC: post.html]
#2

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

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?



[TOPIC: post.html]
#3

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

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).



[TOPIC: post.html]
#4

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

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.



[TOPIC: post.html]
#5

Rob...

[GLOBAL: userInfoPane.html]
Rob...
  • Contributor

  • 329 posts
  • Corona SDK

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



[TOPIC: post.html]
#6

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

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.



[TOPIC: post.html]
#7

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

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?



[TOPIC: post.html]
#8

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

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 ?



[TOPIC: post.html]
#9

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

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.



[TOPIC: post.html]
#10

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

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.



[TOPIC: post.html]
#11

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

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)



[TOPIC: post.html]
#12

Rob...

[GLOBAL: userInfoPane.html]
Rob...
  • Contributor

  • 329 posts
  • Corona SDK

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 :)



[TOPIC: post.html]
#13

Alan PlantPot

[GLOBAL: userInfoPane.html]
Alan PlantPot
  • Contributor

  • 907 posts
  • Corona SDK

I'm surprised to see this topic, because I'm experiencing the total opposite, my touch events have a 3 second (approx) delay when I try to drag an object.

 

I'm testing on a Nokia 920, and generally I get about 30fps depending on how much is happening on screen. I've actually disabled most of the text and print statements to see if this improved things, but it made no difference (I should specify that it did speed up places where text is created).

 

In our game you can drag the gameplay area to move around, and also there is a pulldown menu at the top of the screen. On iOS and Android these both work fine, but on WP8 if I touch the menu, drag down and then release the "began", "moved" and "ended" phases only show up after about 3 seconds (I'm printing them out to check when they happen).

The same goes for the gameplay area, if I drag and then release I have to wait for anything to happen which makes the game seem unresponsive, so you end up dragging again thinking it hasn't worked. 

 

Have I missed something that could be causing this to happen? I'm not going to claim to be an expert at WP8 development, as this is the first app we've tried to port, so any advice would be helpful.

 

Thanks



[TOPIC: post.html]
#14

roaminggamer

[GLOBAL: userInfoPane.html]
roaminggamer
  • Corona Geek

  • 7,541 posts
  • Corona SDK

Hey!  I happen to be in the middle of writing an article on this, but I'll dump some code here to help with this problem.

 

The issue you are seeing is that, touches are not processed frame-synchronous but rather (I assume) in real-time.

 

This allows for multiple move events (from the same source) to occur per frame.  

 

If you are doing heavy calculations based on this input, you will see performance dips in your game/app.

 

To fix this, you need to do what I call, 'touch coalescing'.

 

The following two code samples will demonstrate the difference.

 

Run the samples below and quickly touch and drag your finger across the screen to see the issue.

 

 

Without Coalescing:

local enableShow = true
local events = {}
local group = display.newGroup()
local circle

local rect = display.newRect( display.contentCenterX, display.contentCenterY, 
	                          display.actualContentWidth, display.actualContentHeight )
rect:setFillColor(0.2,0.2,0.2)

local function showEvents()
		if( not enableShow ) then return end

		display.remove(group)
		group = display.newGroup()

		local y = 10
		for i = 1, #events do
			local event = events[i]
			local tmp1 = display.newText( group, event.phase, 10, y, native.systemFont, 8  )
			local tmp2 = display.newText( group, "@ " .. event.time, 100, y, native.systemFont, 8  )
			tmp1.anchorX = 0
			tmp2.anchorX = 0
			tmp2:setFillColor(0,0,0)
			if( event.phase == "enterFrame" ) then
				tmp1:setFillColor(1,0,1)
			elseif( event.phase == "began" ) then
				tmp1:setFillColor(1,0,0)
			elseif( event.phase == "moved" ) then
				tmp1:setFillColor(0,1,0)
			elseif( event.phase == "ended" ) then
				tmp1:setFillColor(0,0,1)
			else
				tmp1:setFillColor(0,0,0)
			end
			y = y + 10
		end

		events = {}
end

rect.enterFrame = function( self, event )
	event.phase = "enterFrame"
	events[#events+1] = event
end

rect.touch = function( self, event )
	if( event.phase == "began" ) then
		events[#events+1] = event
		Runtime:addEventListener( "enterFrame", self )
		circle = display.newCircle( event.x, event.y, 20 )
	elseif( event.phase == "ended" ) then
		events[#events+1] = event
		Runtime:removeEventListener( "enterFrame", self )
		showEvents()
		display.remove(circle)
	else
		events[#events+1] = event
		circle.x = event.x
		circle.y = event.y
	end
	return true
end 
rect:addEventListener( "touch" )

With Coalescing: 

local enableShow = true
local events = {}
local group = display.newGroup()
local circle

local rect = display.newRect( display.contentCenterX, display.contentCenterY, 
	                          display.actualContentWidth, display.actualContentHeight )
rect:setFillColor(0.2,0.2,0.2)

local function showEvents()
		if( not enableShow ) then return end

		display.remove(group)
		group = display.newGroup()

		local y = 10
		for i = 1, #events do
			local event = events[i]
			local tmp1 = display.newText( group, event.phase, 10, y, native.systemFont, 8  )
			local tmp2 = display.newText( group, "@ " .. event.time, 100, y, native.systemFont, 8  )
			tmp1.anchorX = 0
			tmp2.anchorX = 0
			tmp2:setFillColor(0,0,0)
			if( event.phase == "enterFrame" ) then
				tmp1:setFillColor(1,0,1)
			elseif( event.phase == "began" ) then
				tmp1:setFillColor(1,0,0)
			elseif( event.phase == "moved" ) then
				tmp1:setFillColor(0,1,0)
			elseif( event.phase == "ended" ) then
				tmp1:setFillColor(0,0,1)
			else
				tmp1:setFillColor(0,0,0)
			end
			y = y + 10
		end

		events = {}
end

_G.FRAME_COUNT = 0
local function frameCounter()
	FRAME_COUNT = FRAME_COUNT + 1
end
Runtime:addEventListener( "enterFrame", frameCounter )

rect.enterFrame = function( self, event )
	event.phase = "enterFrame"
	events[#events+1] = event
end

rect.touch = function( self, event )
	if( event.phase == "began" ) then
		events[#events+1] = event
		Runtime:addEventListener( "enterFrame", self )
		circle = display.newCircle( event.x, event.y, 20 )
		self._lastFrame = FRAME_COUNT
	elseif( event.phase == "ended" ) then
		events[#events+1] = event
		Runtime:removeEventListener( "enterFrame", self )
		showEvents()
		display.remove(circle)
	elseif( FRAME_COUNT > self._lastFrame ) then
		events[#events+1] = event
		circle.x = event.x
		circle.y = event.y
		self._lastFrame = FRAME_COUNT
	end
	return true
end 
rect:addEventListener( "touch" )

Again, I'm in the middle of writing an article on this, so if I get it accepted you should see a more detailed description in the blog.



[TOPIC: post.html]
#15

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

@roaminggamer is right.  You will receive multiple touch events between frames on WP8.  The same is true on Android.  This is actually a good thing because it ensure that no touch events get missed/dropped by your app.  Especially if you want to implement gesture controls.

 

But that said, odds are your probably have a text object update somewhere in your code.  The majority of performance issues that occur to WP8 developers is due to frequent text updates/creation.  Make sure that you are not indirectly updating text either, such as via our widget library which uses text objects internally.  Other than that, 60 FPS is absolutely possible on WP8.  Even with touch and drag events going on.  Us getting 60 FPS working with a silverlight based WP8 app is actually one of our crowning achievement that other WP8 native developers struggle with.  So, don't lose hope.  :)



[TOPIC: post.html]
#16

Alan PlantPot

[GLOBAL: userInfoPane.html]
Alan PlantPot
  • Contributor

  • 907 posts
  • Corona SDK

I actually removed all text by overriding the display.newText function so that it just drew rects instead, so there is no 'real' text in game. Likewise I don't think there are any widgets using text, and I've overridden the print function too so there should be no slow string operations there either.

 

I'll take a look at @roaminggamer's suggestion in the morning and see if that improves things.

 

Thanks



[TOPIC: post.html]
#17

Alan PlantPot

[GLOBAL: userInfoPane.html]
Alan PlantPot
  • Contributor

  • 907 posts
  • Corona SDK

I had to take a break from WP8 while fixing some things for other platforms, but I've taken another look. In @roaminggamer's approach it seems that you are simply storing all of the events, and then processing them all at once in the frame update. Makes sense given the nature of the problem, though it seemed to me that it would get complicated when hacing to take into account simultaneous touches (not impossible I'm sure, but certainly more difficult).
 
I tried something slightly simpler as an experiment:
local touchIDs = {}
local r = display.newRect(0, 0, display.contentWidth, display.contentHeight)
r:setFillColor(0.5, 0, 0)

local lastX, lastY = nil, nil
function r:touch(e)
	if e.phase == "began" then
		lastX, lastY = e.x, e.y
	elseif e.phase == "moved" then
		if touchIDs[e.id] then
			print("already moved this frame")
			return
		end
		touchIDs[e.id] = true

		r.x, r.y = r.x + (e.x - lastX), e.y + (e.y - lastY)
		lastX, lastY = e.x, e.y
	elseif e.phase == "ended" or e.phase == "cancelled" then
		touchIDs[e.id] = nil
	end
	return true
end
r:addEventListener("touch", r)

local function update(e)
	touchIDs = {}
	print("reset touches")
end

Runtime:addEventListener("enterFrame", update)
This only allows one "moved" event per frame - not ideal for scrolling but I just wanted to see what would happen. It worked as expected: if a touch id had already moved in a frame, it would not move until the next frame when the table tracking the touches was reset.
In the sample with just one red rect to scroll around the screen, and nothing else loaded (no text, no images, no audio) the frame rate ranged from 45-60 when nothing was happening, and would range from ~22-45 when scrolling. Not a constant 60fps, but certainly good enough to play. I found it curious that the fps did drop even when the game consists of one object, but when it dropped to 22fps it was a spike every 10 frames or so rather than a prolonged drop. In my own game, the frame rate drops to 3 or 4fps when touching, from 45+ when not touching. 
 
 
Since text seems to be a major problem for people, I thought I'd try and see if I can change something to do with that. As I've mentioned in a previous post, I've tried overwriting the newText function so that all calls to display.newText actually draw rects instead (it was the easiest way I could think of to remove all text with removing all calls in my code). At any given time there can be upto ~50 text objects in memory in my game (not necessarily all on screen at the same time) so if text was the issue I figured that might work. I put the function overwrite code back in and still only got ~4fps when scrolling.
 
 
I then changed the sample project so it would scroll a group, and added 50 text objects to it. The frame rate was the same as with no text objects (~22-45). So then I tried 50, 200, 500 and 1000 text objects. All on screen at the same time, and the frame rate was still higher when scrolling than in my game with all text objects removed. Admittedly it got progressively slower but with 1000 text objects on screen I still got ~15fps when scrolling their group, which is 3-5 times higher than in my own game.
 
Just before I was about to post this, I did another test in my actual game. I completely commented out all of the code in my "moved" phase, other than the part where I track the touch IDs. So there are no calculations, no x/y movements, no scaling...nothing happening other than setting a few bools to true or false. I also only used one finger. I regularly had 100+ moved events fired in a single frame!
 
Presumably that means that there is something inherently slowing down the frame time. Is there anything else that is known to cause major performance issues? As I say, even with a single rect the fps dropped when scrolling.
 
Any help would be greatly appreciated. I'm well aware that I could have overlooked something which would fix this, and since others seem to be able to get good frame rates I'm hoping someone can help.


[TOPIC: post.html]
#18

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

Alan,

 

You should also know that running your WP8 app via the Visual Studio debugger will severely impact the framerate too.  As in you can't get 60 FPS while running your app via the debugger.  You definitely can't get 60 FPS in the WP8 emulator either.  For best performance, you need to build a "Release|ARM" version of your app, deploy it to your WP8 device (you can use Visual Studio's Debug/Run button), stop the Visual Studio debugger, and then run the app normally by tapping on it.

 

I have a low-end WP8 device (a Nokia Lumia 620) that can run the above at a clean 60 FPS.

 

I do however have another WP8 device (a Nokia Lumia 920) that never gets 60 FPS in a Silverlight app (hovers around 45-55 FPS) and have concluded that its a device specific issue.  I've concluded this by making a native Silverlight app *without* Corona (based on Microsoft's Silverlight Direct3D project template) and discovered that Microsoft's rendering thread would render late every 4th frame.  And this is me rendering absolutely nothing, just a black screen, and it's getting a 45-50 framerate.  There's nothing we can do about that since it's out of our control.  So, some WP8 devices will never give you 60 FPS.  You *might* have one of those devices.



[TOPIC: post.html]
#19

Alan PlantPot

[GLOBAL: userInfoPane.html]
Alan PlantPot
  • Contributor

  • 907 posts
  • Corona SDK

I have a Nokia 920 so that could be it. And thanks for the other pointers, I'll try them out and see what happens. I figured the debugger would have some impact, but didn't realise it would be that bad.

[TOPIC: post.html]
#20

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

Happy to help.

 

I think the debugger is loads better compared to Xcode's, but yeah, I'm thinking it was designed more for debugging normal apps.  Still comes in handy for games though if you need to track down a crash, memory leak, etc.  I also find that running a debug version of your app without the debugger runs pretty fast as well, but a release build will be a bit faster.  Especially on startup since the built app will be smaller (no debug symbols compiled in).

 

Also, some WP8 developers told me that updating their device's operating system from 8.0 to 8.1 improved the framerate for them, suggesting that 8.1 provided some performance improvements, but that wasn't the case for my Lumia 920.



[TOPIC: post.html]
#21

Tapps - enterprise

[GLOBAL: userInfoPane.html]
Tapps - enterprise
  • Enthusiast

  • 75 posts
  • Corona SDK

Hello again,

 

We were doing some more tests, trying to find ways to improve our performance. In general our framerate seem to be ok, not dropping too much, but in some games the touch seemed unresponsive/laggy.

 

We ran some test, printing the phase of the touch event, followed by the time it occured (using system.getTimer) and the difference to the previous one. This is what we got (each touch is separted by a ========):

==========
Phase: began, Time: 13344
Phase: moved, Time: 13620, Diff: 276
Phase: moved, Time: 13621, Diff: 1
Phase: moved, Time: 13621, Diff: 0
Phase: moved, Time: 13623, Diff: 2
Phase: moved, Time: 13624, Diff: 1
Phase: moved, Time: 13625, Diff: 1
Phase: moved, Time: 13627, Diff: 2
Phase: moved, Time: 13628, Diff: 1
Phase: ended, Time: 13629, Diff: 1
==========
==========
Phase: began, Time: 17783
Phase: moved, Time: 18061, Diff: 278
Phase: moved, Time: 18062, Diff: 1
Phase: moved, Time: 18063, Diff: 1
Phase: moved, Time: 18064, Diff: 1
Phase: moved, Time: 18065, Diff: 1
Phase: moved, Time: 18066, Diff: 1
Phase: moved, Time: 18067, Diff: 1
Phase: moved, Time: 18067, Diff: 0
Phase: moved, Time: 18068, Diff: 1
Phase: moved, Time: 18069, Diff: 1
Phase: moved, Time: 18070, Diff: 1
Phase: moved, Time: 18072, Diff: 2
Phase: moved, Time: 18073, Diff: 1
Phase: moved, Time: 18074, Diff: 1
Phase: moved, Time: 18076, Diff: 2
Phase: moved, Time: 18193, Diff: 117
Phase: moved, Time: 18194, Diff: 1
Phase: moved, Time: 18196, Diff: 2
Phase: moved, Time: 18198, Diff: 2
Phase: moved, Time: 18199, Diff: 1
Phase: moved, Time: 18200, Diff: 1
Phase: moved, Time: 18200, Diff: 0
Phase: moved, Time: 18201, Diff: 1
Phase: moved, Time: 18202, Diff: 1
Phase: moved, Time: 18203, Diff: 1
Phase: moved, Time: 18204, Diff: 1
Phase: moved, Time: 18204, Diff: 0
Phase: moved, Time: 18206, Diff: 2
Phase: moved, Time: 18327, Diff: 121
Phase: moved, Time: 18329, Diff: 2
Phase: moved, Time: 18330, Diff: 1
Phase: moved, Time: 18331, Diff: 1
Phase: moved, Time: 18332, Diff: 1
Phase: moved, Time: 18333, Diff: 1
Phase: moved, Time: 18334, Diff: 1
Phase: moved, Time: 18334, Diff: 0
Phase: moved, Time: 18335, Diff: 1
Phase: moved, Time: 18336, Diff: 1
Phase: moved, Time: 18337, Diff: 1
Phase: moved, Time: 18338, Diff: 1
Phase: moved, Time: 18339, Diff: 1
Phase: moved, Time: 18403, Diff: 64
Phase: moved, Time: 18404, Diff: 1
Phase: moved, Time: 18405, Diff: 1
Phase: moved, Time: 18407, Diff: 2
Phase: moved, Time: 18409, Diff: 2
Phase: moved, Time: 18410, Diff: 1
Phase: moved, Time: 18412, Diff: 2
Phase: moved, Time: 18523, Diff: 111
Phase: moved, Time: 18524, Diff: 1
Phase: moved, Time: 18525, Diff: 1
Phase: moved, Time: 18526, Diff: 1
Phase: moved, Time: 18528, Diff: 2
Phase: moved, Time: 18529, Diff: 1
Phase: ended, Time: 18529, Diff: 0
==========
==========
Phase: began, Time: 90336, Diff: 0
Phase: moved, Time: 90338, Diff: 2
Phase: moved, Time: 90552, Diff: 214
Phase: moved, Time: 90553, Diff: 1
Phase: moved, Time: 90554, Diff: 1
Phase: ended, Time: 90555, Diff: 1
==========
==========
Phase: began, Time: 104438, Diff: 0
Phase: moved, Time: 104440, Diff: 2
Phase: moved, Time: 104641, Diff: 201
Phase: moved, Time: 104642, Diff: 1
Phase: moved, Time: 104644, Diff: 2
Phase: moved, Time: 104645, Diff: 1
Phase: moved, Time: 104647, Diff: 2
Phase: moved, Time: 104649, Diff: 2
Phase: moved, Time: 104649, Diff: 0
Phase: moved, Time: 104652, Diff: 3
Phase: moved, Time: 104653, Diff: 1
Phase: moved, Time: 104653, Diff: 0
Phase: moved, Time: 104655, Diff: 2
Phase: moved, Time: 104801, Diff: 146
Phase: moved, Time: 104802, Diff: 1
Phase: moved, Time: 104802, Diff: 0
Phase: moved, Time: 104803, Diff: 1
Phase: moved, Time: 104804, Diff: 1
Phase: moved, Time: 104805, Diff: 1
Phase: moved, Time: 104806, Diff: 1
Phase: moved, Time: 104806, Diff: 0
Phase: moved, Time: 104808, Diff: 2
Phase: moved, Time: 104809, Diff: 1
Phase: moved, Time: 104811, Diff: 2
Phase: moved, Time: 104813, Diff: 2
Phase: moved, Time: 104814, Diff: 1
Phase: moved, Time: 104815, Diff: 1
Phase: moved, Time: 104816, Diff: 1
Phase: moved, Time: 104817, Diff: 1
Phase: moved, Time: 104889, Diff: 72
Phase: moved, Time: 104890, Diff: 1
Phase: moved, Time: 104891, Diff: 1
Phase: moved, Time: 104893, Diff: 2
Phase: moved, Time: 104895, Diff: 2
Phase: moved, Time: 104896, Diff: 1
Phase: moved, Time: 104897, Diff: 1
Phase: moved, Time: 104899, Diff: 2
Phase: moved, Time: 104975, Diff: 76
Phase: moved, Time: 104976, Diff: 1
Phase: moved, Time: 104979, Diff: 3
Phase: moved, Time: 104980, Diff: 1
Phase: moved, Time: 104980, Diff: 0
Phase: moved, Time: 104982, Diff: 2
Phase: moved, Time: 104983, Diff: 1
Phase: moved, Time: 104984, Diff: 1
Phase: moved, Time: 105058, Diff: 74
Phase: moved, Time: 105059, Diff: 1
Phase: moved, Time: 105060, Diff: 1
Phase: moved, Time: 105061, Diff: 1
Phase: moved, Time: 105063, Diff: 2
Phase: moved, Time: 105065, Diff: 2
Phase: moved, Time: 105066, Diff: 1
Phase: moved, Time: 105068, Diff: 2
Phase: moved, Time: 105252, Diff: 184
Phase: moved, Time: 105252, Diff: 0
Phase: moved, Time: 105254, Diff: 2
Phase: moved, Time: 105255, Diff: 1
Phase: moved, Time: 105256, Diff: 1
Phase: moved, Time: 105256, Diff: 0
Phase: moved, Time: 105257, Diff: 1
Phase: moved, Time: 105258, Diff: 1
Phase: moved, Time: 105259, Diff: 1
Phase: moved, Time: 105260, Diff: 1
Phase: moved, Time: 105261, Diff: 1
Phase: moved, Time: 105262, Diff: 1
Phase: moved, Time: 105263, Diff: 1
Phase: moved, Time: 105264, Diff: 1
Phase: moved, Time: 105266, Diff: 2
Phase: moved, Time: 105266, Diff: 0
Phase: moved, Time: 105268, Diff: 2
Phase: moved, Time: 105269, Diff: 1
Phase: moved, Time: 105270, Diff: 1
Phase: moved, Time: 105444, Diff: 174
Phase: moved, Time: 105446, Diff: 2
Phase: moved, Time: 105446, Diff: 0
Phase: moved, Time: 105447, Diff: 1
Phase: moved, Time: 105448, Diff: 1
Phase: moved, Time: 105449, Diff: 1
Phase: moved, Time: 105450, Diff: 1
Phase: moved, Time: 105450, Diff: 0
Phase: moved, Time: 105451, Diff: 1
Phase: moved, Time: 105452, Diff: 1
Phase: moved, Time: 105453, Diff: 1
Phase: moved, Time: 105453, Diff: 0
Phase: moved, Time: 105454, Diff: 1
Phase: moved, Time: 105455, Diff: 1
Phase: moved, Time: 105456, Diff: 1
Phase: moved, Time: 105456, Diff: 0
Phase: ended, Time: 105457, Diff: 1
==========

It seems that between some moved events we are getting a big delay, upwards to 100 ms, and this seems more pronounced close to the initial "began" event. It this delays occurred close to enterFrame events so it seems that it may be affecting the touch events.

 

Any ideas on how to workaround this ?



[TOPIC: post.html]
#22

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

Well, it's not the touch events the is causing lag in your app.  It's what you do within your touch listener is likely the culprit.  Or perhaps it may have nothing to do with your touch listeners and you have some other operations in the background, such as multiple large network.request() operations that is dominating the poor slow dual core CPU and preventing the main UI thread or Direct3D rendering thread from getting invoked on time.

 

So, you said 1 app of yours has this problem and another doesn't.  What features are they using?  What are they doing differently?

Odds are this is not touch related... just that touching and dragging makes latency issues much more noticeable.



[TOPIC: post.html]
#23

Rob...

[GLOBAL: userInfoPane.html]
Rob...
  • Contributor

  • 329 posts
  • Corona SDK

Just catching up on the forum and saw this so had some ideas.Not sure if this will work as just typing it from my head. Sorry about the formatting all the tabs vanish lol

 
 
-----------------------IDEA 1
local allow=true;
local function touchFunction(event)
if allow==true then
if event.phase=="moved" then
allow=false;
--do something
 
timer.performWithDelay(17,function()allow=true;end);
end
end
end
 
yourObject:addEventListener("touch",touchFunction)
 
 
-----------------------IDEA 2
 
local allow=true;
local function touchFunction(event)
if allow==true then
if event.phase=="moved" then
allow=false;
--do something
end
end
end
 
yourObject:addEventListener("touch",touchFunction)
 
local function reEnable()
if allow==false then allow=true end
end
 
Runtime:addEventListener("enterFrame",reEnable)
 



[TOPIC: post.html]
#24

Rob...

[GLOBAL: userInfoPane.html]
Rob...
  • Contributor

  • 329 posts
  • Corona SDK

Oh and I have a Nokia 925. Its very nice and runs between 45-60 fps which is just fine

[TOPIC: post.html]
#25

Rob...

[GLOBAL: userInfoPane.html]
Rob...
  • Contributor

  • 329 posts
  • Corona SDK

oh and you could change the 17 milliseconds to 34 in idea 1 and see if that helps even more as this will be compatible with 30fps.

or just get fps and 1000/fps




[topic_controls]
Page 1 of 2 1 2
 
[/topic_controls]