Okay -- I think I've at least narrowed it down to a cause. Agg uses
fixed-point arithmetic to render at the low-level -- by default it uses
24.8 (i.e. 24 integer bits and 8 fractional bits). Therefore, it can
only handle pixel coordinates in the range -2^23 to 2^23. Both of the
provided examples, after the data has been scaled, draw outside of this
range, which results in integer overflow, hence things going in the
wrong direction etc.
We could change the fixed point in agg_basics.h, but I hesitate to do
so, as it's at the expense of fine detail. We could possibly move to
64-bits, but I'm not sure how easy that would be, or what the impact
might be on 32-bit platforms.
//----------------------------------------------------poly_subpixel_scale_e
// These constants determine the subpixel accuracy, to be more precise,
// the number of bits of the fractional part of the coordinates.
// The possible coordinate capacity in bits can be calculated by
formula:
// sizeof(int) * 8 - poly_subpixel_shift, i.e, for 32-bit integers and
// 8-bits fractional part the capacity is 24 bits.
enum poly_subpixel_scale_e
{
poly_subpixel_shift = 8,
//----poly_subpixel_shift
poly_subpixel_scale = 1<<poly_subpixel_shift,
//----poly_subpixel_scale
poly_subpixel_mask = poly_subpixel_scale-1,
//----poly_subpixel_mask
};
One thing I will look into is whether the line simplification algorithm
can be extended to actually clip the lines when they go outside of the
image range. At the moment, it does some work to reduce the number of
points outside of the image, but it always draws at least one point
outside at its original location. It looks like Agg has some of the
pieces necessary to do this -- whether it's feasible to integrate that
into our existing line simplification algorithm remains to be seen.
Mike
Michael Droettboom wrote:
> Thanks for this.
>
> I believe both of these examples illustrate a shortcoming in Agg when
> the distance between two points on either end of a line is too great.
>
> I'll do some digging around and see what may be causing this and if any
> limits can be adjusted -- I may not get to this today, however.
>
> Mike
>
> João Luís Silva wrote:
>
>> Jan Müller wrote:
>>
>>
>>> Hi,
>>>
>>> The simple code snippet at the end of this mail should plot a single line.
>>>
>>>
>>>
>> I can confirm this bug on Ubuntu running matplotlib svn revision 6827.
>> However I think it doesn't have to do with the log-scale but with the
>> big variations on the x-scale and the custom xscale. I've reproduced a
>> similar behavior with the following script (pan and zoom to see the
>> buggy behavior).
>> --------------------
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>>
>> x = np.array([1.0,2.0,3.0,1.0E5,2.0E5])
>> y = np.arange(len(x))
>> plt.plot(x,y)
>> plt.xlim(xmin=2,xmax=6)
>> plt.show()
>>
>> --------------------
>>
>> Best Regards,
>> João Silva
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
