|
From: <pl...@pi...> - 2009-06-11 02:04:41
|
Ethan Merritt wrote: > On Wednesday 03 June 2009 14:15:52 pl...@pi... wrote: >> Ethan Merritt wrote: > >>> The issue is clearest for the canvas terminal, where "both directions" does not >>> apply. I want to toggle between linear/logscale or linear/transform in the >>> javascript code on the browser. There is no back-connection to the original >>> gnuplot run. >>> >>> I am arguing that it may be preferable to send terminal coordinates corresponding >>> to linear scale, plus some clue how they should be transformed by the viewer >>> upon request. >> I'm wondering about the rationality of this. "Toggling" log/transform >> scaling is really a euphormism for a total replot it seems. You >> fundementally change the x or y scale transformation and have to do a >> full replot of the data, axes and all. > > My goal is to come as close as feasible to replicating the capabilities of > the existing interactive terminals (win x11 wxt qt) in the browser-based > terminals (canvas svg). Except that I've kind of given up on svg :-( > That seems like a great idea and much of that can be done relatively easily. Transforms is tricky. >> This is feasible in a live terminal such as wxt since gnuplot is >> available to do the replotting. In the case of write-once interactive >> terminals I see two possibilities: >> >> 1/ export two renditions of the graph and a trivial js routine to toggle >> them. This could be similar to the line visibility toggle already >> working for svg but on a larger object. I suspect the coding would be >> trivial and fairly portable. > > It's a little worse than that. The axes, including the color palette, > can all be individually toggled. So at least in principle you might have > to export 2^N alternative plots. I agree that it's unlikely in practice > that you would want more than 4 = 2^2 (y or z, colorbar) > > Also you are forgetting that in order to track mouse coordinates, the > browser-side code already has to know how to back-transform the > displayed coordinates. Since we have to provide that capability > anyhow to allow mousing, why not also use it to toggle the axis scaling? Mouse coords are intrinsically low res and one way. As you already noted yourself a one off inverse transformation is easy to do off the plot. Making this repeatable when toggling on and off requires the original data otherwise accumulated errors and over-sensitive parts of the mapping will rapidly cause unacceptable error. The most obvious log transform could quickly produce significant distortions unless the original data was reused. > >> 2/ export enough information and js code for the interactive terminal to >> redraw new axes, tic labels , grid, plot lines, axes labels and >> possibily alter the legend. It seems that this close to the entire plot >> job except parsing the input data. It is reproducing most of what >> gnuplot would do. Gnuplot is no longer a plotter but a preprocessor. >> This seems rather off target in terms of what gnuplot should be doing. > > That overstates the fraction of the total task that would be handed off > to the viewer. To handle zoom/unzoom, the code in gnuplot_mouse.js already > does most of what you list. It's just not that much code. > I agree stuff like toggling lines (already done for svg) zoom (browser std function) are very feasible. My comments were aimed at the subject of axis tranformations. That's a different kettle of fish which, like I said, seems to involve recoding most of what gnuplot does in javescript. This raises another issue: it is no longer within the authors control to asses the mathematical accuracy of the platform doing the work and to verify the graphical output before publishing. He would have to publish without knowing what some arbitrary platform will do to his data whilst mashing it back and forth. I see a lot of the interactive behaviour could be ported relatively easily and I'd love to see this but as far as axis transformation goes I still think you're stuck with the basic issues I outlined. regards. |