Hi Peter, Today Peter Stamfest wrote: > > I thought graph_start and graph_end to be useful for this ... > > This is a misunderstanding. I am using graph_start and graph_end. It is > just that in a standard image, you never know if "13:20" refers to > 2010-10-13 or 2005-09-27 *visually*. > > And this was the major problem, because the rest was so ... simple.
ah ... yes ... I would suggest to have a tooltip come one as the cursor slides over the chart, to show the selected time and value ... > > > > > > I'm unsure what kind of support would be needed to enhance > responsibility: > > > It might make sense to somehow keep data ready for graphing multiple > > > times, but I am unsure about a usable interface in order to keep > rrdtool > > > and this web 2.0 thing separate... > > > > I would have two graphs ... a wide long one below and the detail > > one above ... > > I thought about an approach where the server would generate a longer graph > once and many move requests would access this image and rearrange slices > from it into a new graph, but this has *many* problems: > > - time resolution for an entire graph always is determined by the lowest > time resolution in any part of the graph > - vertical resolution depends on the difference between highest and lowest > value (mod command line settings) > - time axis labelling would be a real pain as well yes > Before settling for the use of rrdtool for graphing, I investigated some > client-side only approaches (using things like > http://www.simile-widgets.org/), but that didn't work very well. > > The current approach has the advantage that it might be "clouded": Just > add more CPU power to RRD graphing and motion gets smoother. One might > also "precreate" intermediate images. > > Another possibility would be to translate all of rrdgraph into javascript > and use an HTML canvas, accessing the RRD data through AJAX. I think this > is what will happen in the long run..... but it would expose raw RRD data > to the world, something that is often not really wanted. I was thinking about preprocessing the data on the server and then sending it to the client ... this would help with keeping the amount of data at bay. cheers tobi > > peter > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers