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

[Dima K. <gn...@di...>]

> On Sat, 29 Sep 2012 17:07:51 -0700
> Ethan Merritt <merritt@u.washington.edu> wrote:
>
> > 5. Adding default window size to the inboard x11 driver so that the 'terminal
> >    xlib' produces plots that have decent defaults when sent to the outboard
> >    driver manually. I'll do this.
>   OK.  It's not just xlib, however.  I think (not 100% sure) that the same 
>   problem arises whenever (ipc_back_fd == IPC_BACK_UNUSABLE), e.g. x11 output
>   from a script run non-interactively.

Still on my list; haven't gotten to it yet.


> > 6. Removing duplicate messages (such as duplicate consecutive V commands) sounds
> >    great. We should do it
>   OK. Low priority because it's relatively rare for normal plots.

I did a first pass at this. Patch attached. Good news is that as expected, the
traffic drops dramatically. Inboard timing drops from about 0.9s to about 0.45s.
The outboard, however, drops from 0.85s to 0.01s! The reason the inboard didn't
drop as much is that it still has to parse the original huge data file. I have
some lingering concerns about the patch I'm attaching. I use ftell() to check to
see that the V commands are indeed consecutive. This might have a non-negligible
cost, so I'd check before committing this.

At this point, my test case is clearly broken since we've been able to optimize
away all its complexity. Is the same optimization valid for P commands? What
would be a good real-world test case where this optimization isn't valid? I'm
thinking of just generating a bunch of discrete points, and sending them over as
P commands. That sounds good, right?


> > 7. General thoughts about speeding up the inboard -> outboard link by making
> >    some things binary. I like binary. Making this switch will probably make some
> >    things break at first, but it'll likely be worth it. If we're touching that
> >    at all, more radical methods may be better. For instance, instead of a V
> >    command for each point, we could have a V command that predeclares a long
> >    stream of points. 
>   We do. That's what the X11_POLYLINE code is for.

That's not quite what I meant. The polyline code we have chunks up data from the
V command we receive before sending it to X. I'm talking about doing a similar
thing, but in the inboard->outboard link: chunk up the V commands before sending
it across. I'll write and benchmark a patch in a bit. Are P and V commands the
main ones to worry about?

dima