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

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

On 10/20/2012 07:46 PM, Dima Kogan wrote:
>>> OK. I revisited this (duplication suppression). Patch attached. I believe this
>>> optimization is equally applicable to P, M, and V. Note that this is all purely
>>> inboard, so there's no active position at all; that's an outboard concept. So
>>> for instance, a duplicated P command would normally draw the same point glyph
>>> multiple times in the same exact position, thus removing the duplication doesn't
>>> change the output. Tell me if I'm misunderstanding.
>>
>> I think you are not unstanding what I was trying to say.  The issue is not whether
>> repeated P commands are redundant, the question is whether or not a M command is
>> needed after the P.  Scenario: one might think that a series of points connected
>> by lines could be drawn as
>>    P(x1,y1) V(x2,y2) P(x2,y2) V(x3,y3) ...
>> But that doesn't work because P(x1,y1) doesn't leave the current position
>> at (x1,y1).  So instead one needs to do
>>    P(x1,y1) M(x1,y1) V(x2,y2) P(x2,y2) M(x2,y2) V(x3,y3) ...
>> My point is that all the M commands may seem redundant but they are not.
>> [NB: This is not the ordering produced by "with linespoints"]
>>
>>> Conclusions:
>>>
>>> 1. ftell() is way too slow
>>> 2. the code with the attached patch is significantly faster than before in the
>>>     best case, and about the same in the worst case
>>
>> I've been too busy to have a serious look at your non-redundancy patch,
>> but at first glance it looks more complicated than necessary.
>> Do you really need to set X11_IPC_LASTDATARUN_NONE for every single
>> command that doesn't change the current position?
>> Other terminal drivers manage just fine without this.
>> If the small set of commands that _do_ change the position (M, V, P, T, ??)
>> track the current position then no one else needs to care.
>
> You're right, I wasn't fully understanding what you meant. The optimization
> implemented in the patch I attached is a bit simpler than what you're
> describing. It only looks for identical, consecutive M, P or V commands, and
> suppresses any found duplicates.

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.

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?

Dan