Jumping this amount of releases could have caused this. I would do a ‘clean start’ with 1.25, meaning wiping the eeprom, deleting or renaming the groundcontrol.ini and start again. I would not put much trust in a calibration with a lagging cursor. Did you check the log.txt from the GC folder if there is some clue there?
I also am on either version 1.10 or slightly older (it was the “most stable” back when it was released). I figure everything has been running fine for me so why break it. Doesn’t seem like anything monumental has come out since then (please correct me if I’m wrong). Was there a reason why you updated?
Are there instructions on how exactly to do this? I’m a little rusty since I haven’t messed with this in a year.
Could not find it in the wiki.
There is a built in ‘wipe eeprom’ in GC, reached with Actions → Advanced.
Fighting with a bug in in fake GC 1.25 mode today, that wipe did not work for me and i used one that i’ve downloaded from an arduino forum. That worked for me. wipe-eepom.zip (824 Bytes)
The groundcontrol.ini should be in your user folder. I rename it, and GC will create a new one, but with all values set to default. I edit the main settings in the new .ini like motor-distance etc. with the values that i know and can read out of the old .ini. I hope that gives GC a better start for improved calibration restults.
I think I might see the problem - Display Color 262,144 (6bits/color)
The 6 bit color adaptor it probably not got a very current display driver. In fact I bet it was written in Windows 98 days.
My guess is this is a Vista wrapper driver wedged into Windows 7 and it is having a hard time communicating with modern software framework. The 6 bits have to be calculated for each pixel, most likely an 8 bit routine then re-interrupted taking extra time.