Michael Droettboom wrote:
> Eric Firing wrote:
>
>> Michael Droettboom wrote:
>>
>>> Eric Firing wrote:
>>>
>>>> Mike, John,
>>>>
>>>> Because path simplification does not work with anything but a
>>>> continuous line, it is turned off if there are any nans in the
>>>> path. The result is that if one does this:
>>>>
>>>> import numpy as np
>>>> xx = np.arange(200000)
>>>> yy = np.random.rand(200000)
>>>> #plot(xx, yy)
>>>> yy[1000] = np.nan
>>>> plot(xx, yy)
>>>>
>>>> the plot fails with an incomplete rendering and general
>>>> unresponsiveness; apparently some mysterious agg limit is quietly
>>>> exceeded.
>>>>
>>> The limit in question is "cell_block_limit" in
>>> agg_rasterizer_cells_aa.h. The relationship between the number
>>> vertices and the number of rasterization cells I suspect depends on
>>> the nature of the values.
>>> However, if we want to increase the limit, each "cell_block" is 4096
>>> cells, each with 16 bytes, and currently it maxes out at 1024 cell
>>> blocks, for a total of 67,108,864 bytes. So, the question is, how
>>> much memory should be devoted to rasterization, when the data set is
>>> large like this? I think we could safely quadruple this number for a
>>> lot of modern machines, and this maximum won't affect people plotting
>>> smaller data sets, since the memory is dynamically allocated anyway.
>>> It works for me, but I have 4GB RAM here at work.
>>>
>> It sounds like we have little to lose by increasing the limit as you
>> suggest here. In addition, it would be nice if hitting that limit
>> triggered an informative exception instead of a puzzling and quiet
>> failure, but maybe that would be hard to arrange. I have no idea how
>> to approach it.
>>
> Agreed. But also, I'm not sure how to do that. I can see where the
> limit is tested and no more memory is allocated, but not where it shuts
> down drawing after that. If we can find that point, we should be able
> to throw an exception back to Python somehow.
I figured this out. When this happens, a RuntimeError("Agg rendering
complexity exceeded") is thrown.
Cheers,
Mike
--
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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
