Re: [PATCH] x11 terminal respects the requested aspect ratio

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 21 October 2012, Daniel J Sebald wrote:
> On 10/21/2012 12:08 AM, Dima Kogan wrote:
> >> On Sat, 20 Oct 2012 23:23:35 -0500
> >> Daniel J Sebald<dan...@ie...>  wrote:
> >>
> >> Dima,
> >>
> >> Is this optimization something that should happen?  The duplicate moves
> >> is no issue.  However, I'm not completely comfortable with tossing out
> >> duplicate P and duplicate V, in a general sense.  I think in x11's
> >> current form throwing out duplicates won't cause an issue.  However,
> >> from the general viewpoint, it probably isn't good practice.
> >>
> >> Imagine I have some results with data points (0.123,0.321) (0,0) (0,0)
> >> (0.654,0.456).  The data appearing on the graph is then (0.123,0.321)
> >> (0,0) (0.654,0.456).  Say my terminal can create a file version of the
> >> graph, such as Qt currently does.  Then I have some secondary program
> >> that can import that graph and somehow pull out the data points for
> >> processing (e.g., statistics).  The resulting data would be missing one
> >> of the original samples, thereby throwing off statistics.  I have no
> >> specific example, but I'm imagining things like CAD programs with 2D
> >> splines interpolation that might have a point on top of another.  Or,
> >> think of the googlemaps where one can interactively drag points around.
> >
> > I'm only looking at the x11 terminal, and have no intentions of applying this
> > elsewhere, although this could certainly be done if one so desires. I would
> > argue that the main purpose of gnuplot is visualization, and we're allowed to
> > interpret the input in whichever way we like, as long as the visualization
> > result doesn't change. If somebody wants to manipulate the data, they should be
> > manipulating the input data, NOT the gnuplot output. At the very least this is
> > true of the x11 terminal. On top of that, the terminal already makes
> > modifications to the input: scaling and quantizing to the terminal coordinates.
> >
> >
> >> Is it correct that the scenario you have in mind is where the user plots
> >> a relatively low frequency function and extremely oversamples that
> >> function?  This optimization is then sort of correcting something the
> >> user should know better about.  How often will this situation arise?
> >
> > Yes, this is for heavily oversampled data. Most of the time this optimization
> > would do nothing, probably, but for particular data sets, the performance gains
> > are pretty big (see some earlier posts in this thread). This optimization is
> > pretty low-hanging fruit, so I think we should apply it. If I want to plot a
> > huge, smooth data set, it'd be great if I didn't have to manually downsample it
> > first, and if gnuplot was able to efficiently deal with it all by itself.
> >
> > dima
> 
> Mmm, not sure I agree with that.  Predominantly, the users of gnuplot 
> will be scientifically oriented folks, and I don't think that it is too 
> much of an expectation that the user know how to downsample data, and 
> properly.  Either that, or be content with a slow plot.
> 
> I've been an advocate of gnuplot support in Octave (vice-versa depending 
> upon one's viewpoint) for this very reason.  That is, if one is working 
> with large data sets and wants to do some processing before plotting, 
> say lowpass filter then decimate the data, Octave is just the tool to do 
> that quickly and simply.
> 
> I admit that the X11 plot is lacking in things like antialias filtering, 
> but if anything it would be better to add such features than to optimize 
> on the basis of the terminal's deficiencies.
> 
> Dan

Dan, I think you have misunderstood the context of this patch.
The idea is to tailor the output streamed from gnuplot to the 
separate display program gnuplot_x11.  I can think of no scenario
in which that stream would be captured for later analysis in a 
different tool.  We have plenty of other output modes where that
might make sense, but not the pipe to gnuplot_x11.  Downsampling
occurs when the user shrinks the x11 plot display window down 
to some small size.   Inside gnuplot the resolution is as high
as ever, but that cannot be displayed in the tiny plot window.
Conversely if the user maximizes the plot display window, it
makes sense to up the resolution of the plot commands sent to it.

	Ethan