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

[Daniel J S. <dan...@ie...>]

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