We have an in-game cursor following the hardware cursor in the Corona Simulator (not Desktop build).
In daily build 2843 the in-game cursor follows the hardware cursor very well at a high framerate.
The latest 2883 build has a laggy in-game cursor that follows at half the rate of the hardware cursor.
Something changed with mouse input polling?
Hi John. Engineering has asked for a bug report so we can see what is going on. We can’t reproduce this but we suspect we know when it happened. If you could zip up a simple project that demonstrates the problem that would be great.
Also we need to know:
Are you using a Mac or Windows?
Are you set to 60 fps in your config.lua?
Thanks
Rob
Also John, can you record a 60fps video that shows the lag? We have a report of a different lag and we are trying to figure out what changed. You can share it with me via email would be great.
Thanks
Rob
Hi Rob, we created a small project and did the test but the lag didn’t show up. I’ll create a video and see if that works.
Here is the video:
https://player.vimeo.com/video/171104309
This was done on a Mac – our main dev platform. Config is set to 60fps.
v2843 (smooth) is on the left, v2902 (not smooth) is on the right.
Thanks John, I’ll get this to the engineers.
Thank your for feedback, John. We still trying to pinpoint what subsystem causes this effect. We have suspicion that some general performance issue causing this unfortunate effect. Basically, it’s possible that something causes frame-rate to drop once in a while. It is rather hard to pinpoint what exactly is the cause, especially if we don’t have a project where we can see similar behaviour. We still working trying to figure out what is going on.
Another thing which would help us out, if you could provide which version causes this lag. If someone would have about 10 minutes to spare with good internet connection it wouldn’t be hard to pinpoint 2 builds which caused this issue:
Basically download build (2902+2843)/2 = 2883. If game is still broken, download 2863 ((2883+2843)/2), etc. It should take about 6 such iteration to pinpoint exact moment we introduced the issue. This will help us greatly.
Another option to help us is to provide with project. We respect our customer privacy and would use it exclusively for pinpointing this particular issue, after what we’ll delete the it. If it is possible, you may send download link with private message. I understand that this may be not a suitable option. Finding which version caused lag, though, would help a lot.
John, did someone in your group file a bug case about text field lag? Are you seeing this cursor lag issue after creating a native text field object?
Thanks,
Tom
I decided to make a little chart. This chart shows how in only 6 downloads (worst case scenario) pinpoint exact build which introduced a bug. Start at top (2872). If you see a lag, go to right, “Bug” arrow. If no lag - follow “OK” arrow. All labels are clickable and would initiate downloading of Corona SDK of appropriate nightly build.
Here’s chart: https://dl.dropboxusercontent.com/u/2658771/cursor_bug.svg
Red arrow and circle indicates last build without a bug.
vlads, the lag started on build 2853. For some reason there was no build 2852. Build 2851 runs the cursor at 60fps and feels great.
Unfortunately, the Version Lookup diagram didn’t help. Starting at build 2872 the build was buggy which meant I would only go left toward higher builds which would never isolate the problem build.
Also, yes Tom, Ian Dunbar from this project also submitted a bug about text field lag. I’ll check with him about it tomorrow.
2853 has changes around display.capture() and display.save(). Are you doing anything with those two API calls? I know some people using snapshots will use them to create textures on the fly.
Rob
Thanks a lot for feedback! Narrowing it down to two builds helps immensely.
Unfortunately there were a lot of changes between 2851 and 2853. We will brainstorm what may cause such effect on Monday. Meanwhile, my first guess would be about Console. May I ask to do a small test on 2853:
Disable console by typing this command in terminal window:
defaults write com.coronalabs.Corona\_Simulator no-console YES
Restart Corona. You should not get get Console Window. Is bug still persists?
To restore Console run
defaults delete com.coronalabs.Corona\_Simulator no-console
Another quick test, which would help us to narrow down possibilities, is to build Mac app (Command+Control+B ), and checking if bug still persists there.
P.S. Sorry about the chart… Script I wrote to generate it had a mistake - reversed arrow labels. I fixed it now, but you already have it figured out.
So, here is build 2852 - https://dl.dropboxusercontent.com/u/2658771/CoronaSDK-2016.2852.dmg
May I ask to test with it so we can further narrow down the scope?
Build 2852 is LAGGY, even without the console up. 
I turned off the console, ran that build and the console did not come up.
Can you try running the 2853 (or higher) Simulator in borderless mode (e.g. Window > View As… > Borderless > iPad @2x ) to see if that makes a difference? I’m having the devil of a time reproducing the lag with or without a skin so I can’t judge the difference with any accuracy myself but, if you can see it, that might explain why this started with 2852.
The issue concerns layering native controls on the OpenGL canvas and was introduced by Apple in OS X 10.10. We filed a bug but it hasn’t been fixed so we’re reduced to workarounds and, as you know, that means fixing one thing can affect another.
I think this is fixed this in Daily Build 2908 … let me know how it goes. If it doesn’t seem to be fixed, please try either with or without a Simulator skin and see if that makes any difference. A related issue involving a performance hit after creating a textfield is definitely fixed but that was easier to reproduce.
Hi John. Engineering has asked for a bug report so we can see what is going on. We can’t reproduce this but we suspect we know when it happened. If you could zip up a simple project that demonstrates the problem that would be great.
Also we need to know:
Are you using a Mac or Windows?
Are you set to 60 fps in your config.lua?
Thanks
Rob
Also John, can you record a 60fps video that shows the lag? We have a report of a different lag and we are trying to figure out what changed. You can share it with me via email would be great.
Thanks
Rob
Hi Rob, we created a small project and did the test but the lag didn’t show up. I’ll create a video and see if that works.
Here is the video:
https://player.vimeo.com/video/171104309
This was done on a Mac – our main dev platform. Config is set to 60fps.
v2843 (smooth) is on the left, v2902 (not smooth) is on the right.
Thanks John, I’ll get this to the engineers.
Thank your for feedback, John. We still trying to pinpoint what subsystem causes this effect. We have suspicion that some general performance issue causing this unfortunate effect. Basically, it’s possible that something causes frame-rate to drop once in a while. It is rather hard to pinpoint what exactly is the cause, especially if we don’t have a project where we can see similar behaviour. We still working trying to figure out what is going on.
Another thing which would help us out, if you could provide which version causes this lag. If someone would have about 10 minutes to spare with good internet connection it wouldn’t be hard to pinpoint 2 builds which caused this issue:
Basically download build (2902+2843)/2 = 2883. If game is still broken, download 2863 ((2883+2843)/2), etc. It should take about 6 such iteration to pinpoint exact moment we introduced the issue. This will help us greatly.
Another option to help us is to provide with project. We respect our customer privacy and would use it exclusively for pinpointing this particular issue, after what we’ll delete the it. If it is possible, you may send download link with private message. I understand that this may be not a suitable option. Finding which version caused lag, though, would help a lot.