There sure are a lot of abstractions in web tool kits and ajax libraries. When are the browser vendors going to get off their asses and start doing things in a standardized way so abstractions aren’t necessary?

Comment by Andy — November 22, 2007

@SloMo:
Could you tell me which browser you’re using, and which CPU you have? Also, whether you have Firebug enabled if Firefox? On my system, under Safari and Firefox, the scrolling/zooming is as fast as Google/Yahoo finance charts. (Mac Pro). If there’s a performance problem, I’d like to identify it and fix it (I can scale the number of points plotted while animating/dragging) One thing I’ve noticed that slows it down is having a GMail chat window open.

@Alex: It uses a lot of resources if you load large datasets, like the 600kbyte Fedfunds (18,000 points), but if you’re plotting trivial datasets like Dojo or Plotkit, it uses less resources and is much more on par with a typical GWT application. You can also configure it in non-interactive mode (no zooming/panning) which cuts down on resources, as well as using server-side rendering if you don’t want any JS at all.

I am concerned however by the performance and resource concerns and I want to improve on them as much as possible, so if you have any advice or feedback, please email me personally or send to chronoscope@googlegroups.com

Opps, I found a issue in the animation routine that causes the interpolation to lag on some platforms (tried it on my PC), I’ll put up a new build after Thanksgiving which should fix some of the perceived slowness when animating.

The Flash-based Google finance charts are around 10 times faster on this machine. GWT charts are DHTML-based, I’m guessing?

Comment by SloMo — November 22, 2007

@SloMo,
It uses the Safari/WHATWG element, in the next version, it will use Flash. When animating, the chart draws a reduced resolution version of the curve and then at the end, switches to the high res version (rendering hundreds or thousands of points). One problem is, if you’re dragging or pressing the buttons multiple times, the last step can take very long on slower machines, so the animation seems to get stuck.

The other issue is, it renders 8 frames of animation no matter what. On Safari and FF (and a 3Ghz PC), I had no problems getting over 8 frames per second, but I didn’t test it on FF Linux. I’m going to switch it to a time interpolated animation so that transitions take 1 second no matter what, only the # of frames changes. I’m also going to make the ‘high res’ rendering pass wait until the user has stopped inputting commands, and also tone town the resolution a little (perhaps render 1/10 the # of points)

Thanks for the help though. I happen to have a 2Ghz Dell sitting closet, so I’ll put Linux on that and use that as one of my test machines.

@SloMo,
I believe I have a patch which addresses the performance issue hopefully. I will publish the fix on my blog tommorow sometime, see timepedia.blogspot.com for news when it goes live. Could you try it again sometime tommorow and let me know via a blog comment or direct email to cromwellian at gmail.com. I really appreciate it, thanks.

Ok, for anyone who had performance issues I pushed a new version to the production server which I hope will have a better user experience. I recommend using the arrow keys on the keyboard to zoom around the chart. Hopefully there are no regressions.

Putting axis labels inside the plot area is an option we
haven’t exposed in GSS yet, but someone could implement
a new RangeAxisRenderer for that if we don’t do it first.
Better control of axis label precision is also coming soon.

We mention Timeplot on our about page — it’s polished,
works great, and Stefano is awesome.

That said, we’d love to hear any specific suggestions for improvement you might have as a Timeplot user.