[dojo-contributors] Chart Markup Proposal
ttrenka at gmail.com
Wed Aug 29 19:42:38 EDT 2007
On 8/29/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
> Hopefully Jared can chime in on this too, but here's my thinking...
> > One thing we need to keep in mind is that charts (especially
> > large charts) can take a long time to render, particularly if
> > there are a lot of points on it.
> Yup, understood. Although, in the case of handling a few onNew()
> notifications, the chart might be able to very quickly draw a few new
> data points on the existing plot, rather than needing to re-render the
> entire plot.
It doesn't really work that way. Most of the charts in question will be
based on paths, which expect a full path definition as opposed to being able
to just append a few points to the end of it; it kind of sucks but that's
the way it works :(
> I'm not interested in throttling unnecessarily but at the same
> > time if we're talking about something pushed to the desktops of,
> > say, a Fortune100 company with a lot of Windows 2000 machines all
> > running FF1.5, the perception will end up being "Dojo sucks", and
> > that's not something I want to foster.
> > At the same time, we could probably do something where update
> > notifications are caught by the charting engine and rendered
> > periodically.
> That sounds good. It seems like a useful idea to set things up so that
> update notifications don't automatically trigger a re-rendering. The
> updates and update notification could still happen frequently, but the
> charting widget could buffer them and then choose to only re-render
> after a given interval.
Right, exactly what I was thinking.
> The main thing to think of here is to let the charting widget
> > determine when an update is made (as opposed to a Store); from
> > experience I've found that this is (by far) the best method.
> I'm not sure I'm parsing that sentence correctly. If the word "update"
> basically means "re-rendering" (rather than changing the data in the
> datastore cache), then the sentence makes sense to me, and it sounds
> like a good plan. Am I reading it right?
You are, in fact :)
> Plus we need to consider that the chart widget itself may be
> > the one asking the store for the update...
> Right now we don't have any way for a widget to ask the store for an
> update. That's not a pattern we've designed for. The closest thing you
> could do is re-issue the original fetch() query again, and then process
> the results a second time, and a third time, and so on -- but if you did
> that, you'd have to either (a) blindly redisplay the entire result set
> even though probably no data has changed, or (b) do a diff to compare
> the old result set to the new result set, and only redisplay if there's
> been a change. You'd have less screen flicker and/or less code in the
> widget if you watched for onNew/onDelete/onSet notifications and only
> re-render then, after you find out a change has really happened.
That's true, and that's what I was thinking about (the former). There's an
unfortunate disconnect when it comes to timed things and non-timed things,
and (like I said, from experience) I kind of need to support both :(
Fortunately the charting engine was designed so that you can take the "main"
axis (usually x), set the range on it, and then filter out values that don't
fall within it, but that may incur some additional overhead as well (think
BETWEEN in SQL).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors