Touch moved event firing too quickly ?

CoronaCards (Corona in native apps) CoronaCards for WP8
#21

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.

#22

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)
#23

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

#24

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

#25

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.

#26

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

#27

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

#28

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.

#29

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.

#30

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.

#31

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.

#32

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 ?

#33

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.

#34

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
[lua]
 

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

[/lua]

#35

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

#36

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

#37

@Tapps,

I’ve heard that you are still have performance issues with you touch event.  I’m wondering, are you updating text with the “Font-Manager” bitmap font library via your touch listeners?  It’s come to my attention that the “Font-Manager” library has performance issues due to a lot of wasteful string parsing and regular expression it does every time you update a small amount of text.  During my testing, I’ve discovered that updating a small amount of text via “Font-Manager” can take about 15-30 milliseconds.  I shared my findings here…

   http://forums.coronalabs.com/topic/53450-performance-problems-with-newtableview/?p=279041

So, if you are using the free “Font-Manager” library, then that might be the cause.

The “bmFont2” bitmap font library was a lot faster during my testing.

I haven’t tried “TextCandy” yet.

#38

Hello Joshua,

In this particular case, we are not updating any text based on the touch event or making large network requests. The behavior we see is that dragging in it self seems ok, although a bit slower than in other platforms, but the we see a big delay between dragging the finger across the screen and the object actually moving.

We tried to update the position only once per “enterFrame” event but didn’t see any noticeable improvements. Something that we noticed during our tests is that the performance of the touch is related to number of display object on screen, even if they are static.

We are trying to find more stuff to test, see what could be causing this, any ideas ?

#39

Just to reinforce Tapps’ comment, it pretty much covers what happens to us too.

Updating positions only once per frame, but the frame time gets slammed when moving so there is a big delay between moving your finger and the object moving. You end up with very jumpy movement.

#40

Odds are its what’s being updated/rendered is what is causing the performance issue that you 2 are seeing.  Would you 2 mind sending us your projects?  This way it’ll be a lot easier for us to isolate what the issue is, because right now I’m just guessing and I have no idea what you are running into.  I can get you 2 in contact with David to send us your projects securely if you’re willing.

Edit:
Alternatively, you can zip up your project and send it to us via the “Report a Bug” link at the top of this page.  There is a size limit though (I think it’s 30 MB) so you should make sure to “Clean” it first (ie: delete the compiled files).