I've had this happen off and on for a while, and I can't tell what causes it, so I'm bringing it here.

When I study in Chrome (my browser of choice), I occasionally run into an issue, maybe as much as a quarter of the time, where each item has a lag of anywhere from a half-second to a second before it moves on to the next item. It's not so bad at first, but it adds up after a while. I haven't been able to pinpoint a cause - it doesn't seem to matter whether I'm on battery or plugged in, what's running in the background, what power profile I'm using, or anything else. Sometimes it can be fixed by closing and reopening the browser, but about half the time it continues to lag a bit after each item. I'm on Chrome (11.0.696.65 beta-m), though it was going on before they reached 11.x beta, probably before 10.x as well.

It's enough that I've been using IE9 (64-bit) to study lately, which has its own issues, such as telling me I need Flash every time I log in, and asking me to install the Wacom plugin every time, which doesn't seem to work anyway on IE9 x64.

I have the same configuration. I have noticed the slowing down, but assumed that was just general Flash bugginess. Like you restarting the browser usually solves it. Haven't tried IE9 (brr...) yet.

By the ways, in a probably unrelated bug, I often hear, in a faint echo, the Chinese voice say other words from my vocabulary. It's a bit eerie, though no big deal. Maybe this extra work is slowing things down?

I have the same problem. I stopped using exclusively Chrome for that reason.

As FatDragon said, it's not that noticable at first, but over time I found it really impossible to study on Chrome because it drove me crazy that the delay after non-writing prompts was actually longer than the time that I actually spent on it.

Although I mainly use my tablet, I haven't had any problem on chrome, I download the latest beta on www.filehippo.com... Also have the latest adobe flash, you can also find it there I think.

Maybe I simply didn't notice the delay. And don't like IE9 at all!

@Kai: those would be the ghosts of Skritter:

http://www.skritter.com/forum/topic?id=5677415

Hmm, Nick is the flash guy but it sounds like it might be memory related. Hit Ctrl-Alt-F to bring up a little square in the upper left corner that will show you how much memory it's using. Then you can see if there's a correlation between memory usage and slowness. We wouldn't want to drive people to use Explorer!

Ha, for what it's worth, IE isn't getting any other business from me. I'll add one more bug with IE as well - the horizontal and diagonal guide lines are normal in the practice square, but there's no vertical line. It's not a huge issue but it does get a little disorienting after having all four lines for so long.

I'll try the memory thing and report back if I see anything worth reporting.

Thanks for the hint with the memory, I will check this. I attributed the problem so far to me being in China. It is really annoying.

I wrote a feedback some time ago,but did not get a response. I was wondering if there could be some kind of cache for items, so they do not need loading from the server but come from your local disk thus reducing the problems with server responses. On the other hand this might not work as your server has the main recognition function instead of the client... Especially new items are prompted quite often and this could speed up practicing significantly. I often wait half a second to a second after writing prompts to show the next item.

I also noticed recently that somehow I could already write squiqs but they were not accepted, although the squig was at the right position. Then suddenly writing it again it is taken as if the matching squig loaded from the server had not been completely there yet.

Regards,
Alex

Edit: Removed. Some of what I said might not have been right.

At any rate, some bits and pieces are handled locally. So it's not all waiting for the server.

OK for me Internet Explorer 9 is better for Skritter than Chrome. Thanks @FatDragon for pointing this out. I am on a not-terribly-powerful-but-decent Win7 laptop (Toshiba Satellite T130) with 4 Gig of RAM.

Many strokes on Skritter on Chrome feel laggy to me now compared to Skritter on IE (strokes, not items, so it may be a different problem from FatDragon's). I feel like I can work faster on IE. I'll go on testing both browsers because Chrome is my browser of choice and usually better and faster at everything, but for Skritter Microsoft wins this round.

The only significant difference I see with the Ctl-Alt-F Flash debug thing is that IE is about 50 FPS, while Chrome is closer to 40.

Another difference may be that IE smoothly auto-installed the Wacom tablet plugin, while I am not sure whether the plugin is installed and/or working on Chrome.

@scott: ha, the ghosts of Skritter, thanks, good one!

@Kai who's Eric?

@jww1066 oops I meant @scott. I guess I got the name wrong because Scott's last name is Erickson. Either that or Skritter is scrambling my brian. I mean brain.

@Kai I thought there was an invisible Eric. ;)

As for the delay, I was noticing this yesterday as well but this morning it seems to be much better. I'm using Chrome 12.0.742.30, Flash player 10.3.181.13 on Windows XP.

James

People call me Eric by accident all the time. I respond to either name at this point, really!

I'm on the road at the moment and have lots to do, but I've put it high on my list to do an in-depth investigation of performance across various browsers to try to figure out what we can do to get consistent speed. At the Chrome keynote yesterday, they were talking about 10x improvements in JavaScript speed, but all I see is it getting slower! There are definitely solutions out there to be had once I fire up my profilers.

I've noticed better speed in IE9 as well, but it kind've throws me off - I'm used to a couple ms of lag on each stroke in Chrome, so the ultra-snappiness in IE throws me off. As does the lack of a vertical guideline and a working Wacom plugin (probably due to x64).

I've been using Chrome again for the past couple days and haven't run into any issues lately. If I see the issue crop up again I'll try the dev. console.

@scott Now that you mention it, you do look like an Eric.

Okay, it's happening right now - on battery (it seems to happen more on battery, but not exclusively). It's only mild, only some items have a delay and it's shorter than it gets sometimes. The FPS is fine, the number below it - MS - is hovering at 17, and the memory is hovering around 55-60, which is higher than normal I think but should hardly be a drain on a system with 4GB in a fairly light usage situation.

Edit: 10 minutes later memory's up to about 67 and the lag is worse. Even after closing the study tab and opening a new study tab it was almost instantly at 60 MB. I've got a flash game (doodle god 2 @ kongregate) open in another tab, which might have an impact on it. Either way, I'm off to IE for the moment. I'm going to see how IE9 32-bit compares to 64-bit for Skritter.

FatDragon, can you do more testing with respect to having that Flash game open or closed in the other tab? The memory usage is usage across all Flash, so that other game does add in there. It also takes CPU from Skritter, too, as well as anything else running a lot of JavaScript. Also, your laptop will probably run its CPU slower when on battery.

When I sit down for the second half-hour of the day, I'll run it on IE with a couple flash games open in other tabs and see what happens.

One of the worse occurrences in recent memory, the one that drove me to try IE9, was a situation in which I was on AC power, fully charged, high performance power profile, and the only other thing going on was a download in the same Chrome window as Skritter, so I doubt that Flash memory drain or other CPU drain would be the exclusive causes, though they might be partial causes.

I've also found, incidentally, that power saver versus high performance doesn't seem to change anything when it's happening on battery, so I don't think it's a CPU thing, since High Performance can run the CPU at higher speeds so it should improve performance in that situation.