Re: Action for 4.2 [was Re: with image and reversed x-axis]

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

Ethan Merritt wrote:

> Not sure I follow you.  We know that one driver does it correctly
> when given the info already being passed down by the core.
> So why would there be any changes needed in the core code?

Because two wrongs sometimes make a right.  (Not saying that there are two wrongs, just that we aren't certain yet.)

> The brokeness must lie in the individual drivers, or at least
> that's what it seems to me.
> 
> 
>>If it is a decision between adding a comment "known bug" and making
>>an alteration to make that bug less egregious vs. simply fixing the
>>bug even though it may mean twice the amount of work, I'd go with the
>>latter.
> 
> 
> I'm not so much concerned about the amount of [someone else's]
> work, but the chance of breaking other things while fixing this one.
> I am extremely wary of fixes that touch more than a line or two
> at the stage of the game.  I'd rather go with a warning about a
> known bug than ship significantly revised code that has had minimal
> testing.

This is why I say first decide how the core should be.  Make that one change in CVS.  Then, everyone can make the appropriate adjustment in the terminal drivers.

Let me explain what I think the change to the core code would be.  The following hunk of code figures out the starting point in the raw data along with the integer values to jump through that raw data to get the proper orientation:

	/* Set up parameters for indexing through the image matrix to transfer data.
	 * These formulas were derived for a terminal image routine which uses the
	 * upper left corner as pixel (1,1).
	 */
	if (fabs(delta_x_grid[0]) > fabs(delta_x_grid[1])) {
	    line_length = K;
	    i_start = (delta_y_grid[1] > 0 ? L : 1) * K - (delta_x_grid[0] > 0 ? K : 1);
	    i_delta_pixel = (delta_x_grid[0] > 0 ? +1 : -1);
	    i_delta_line = (delta_x_grid[0] > 0 ? -K : +K) + (delta_y_grid[1] > 0 ? -K : +K);
	} else {
	    line_length = L;
	    i_start = (delta_x_grid[1] > 0 ? 1 : L) * K - (delta_y_grid[0] > 0 ? 1 : K);
	    i_delta_pixel = (delta_x_grid[1] > 0 ? +K : -K);
	    i_delta_line = K*L*(delta_x_grid[1] > 0 ? -1 : +1) + (delta_y_grid[0] > 0 ? -1 : +1);
	}

Basically, one has to sit down and think through all the various combinations.  I wrote out a little logic table, which is probably in documentation somewhere.

The details of that aren't important.  We are going to have axes reversals; that doesn't change the line length.  But in this formulae are conditionals based upon sign of delta_x and delta_y.  So, if this routine had access to information about the invertedness of the axes it could make the adjustment.

Say axis_x_polarity and axis_y_polarity are two variables reflecting reversedness.  Say +1 means non reversed, -1 reversed.  Then, in the above formulas change every

delta_x_grid[#]  ->  delta_x_grid[#]*axis_x_polarity
delta_y_grid[#]  ->  delta_y_grid[#]*axis_y_polarity

That will put the data in the correct orientation I think.  Otherwise, it is going to be up to the terminal driver to reorder the data if that is not an option to the tools used by the driver.  I'm fine with that, but let's make sure we want to go that route first.

Similarly, it wouldn't be too difficult to write a formula to send over the proper coordinate for the upper right corner.


Well, I'm curious how this behaves...

#define AXIS_MAP(axis, variable)		\
  (int) ((axis_array[axis].term_lower)		\
	 + ((variable) - axis_array[axis].min)	\
	 * axis_array[axis].term_scale + 0.5)

Here's a little experiment.  I've added an extra printf to the x11 driver as follows:

TERM_PUBLIC void
X11_point(unsigned int x, unsigned int y, int number)
{
fprintf(stderr,"P%d %d %d\n", number, x, y);
    PRINT3("P%d %d %d\n", number, x, y);
}

And tried the following:

gnuplot> set xrange [-10:10]
gnuplot> plot x with points
P0 325 236
P0 362 274
P0 398 312
...

gnuplot> set xrange [10:-10]
gnuplot> plot x with points
P0 3961 236
P0 3924 274
P0 3888 312
...

The first plot is visually a positive sloped line.  The coordinates coming over from gnuplot core are positive sloped.

The second plot is visually a negative sloped line.  The coordinates coming over from gnuplot are now also negative sloped.

We're plotting the same function.  Therefore, I'm concluding that the core routine assumes the terminal coordinate system is conventional Cartesian, and the core is where the axis direction is handled.

We should then have the image routine correctly orient data and choose the proper coordinate to correspond to the terminal driver image upper left corner.

Agreed?

I can do this over the weekend and make sure x11 is working.  That would serve as an initial patch.  Then we can fix others.

Dan