ah...@cs... wrote: > John (and others), > > I've made a quick change to the svg backend to cull the data, see attached > patch. I haven't tested it extensively, but it seems OK. It culls both > lines and polygons out of svg output. Allan, Looks good, and the basic idea should be generally applicable. It can be sped up (probably), and the code made more compact, by using numpy arrays; but this can wait. > > About making it general across backends: I've looked a bit at how things > get rendered, and here is what I understand: We can only do the culling in > pixel coordinates, since the height/width of the figure is in pixel units. > > The transform from unit to pixel coordinates either happens in > Line2D.draw() (such as SVG), or in the backend's draw function (such as > for agg). Therefore we could only generalize for the case where the > transform is in line2d, and even then, it looks simpler to do it in the > backend to me since that is the only place we conveniently have all the > pixel information we need. Maybe I have misunderstood, though. The relevant transformation is between data coordinates and pixel coordinates, so provided the transformation is from one rectilinear system to another, it should be possible to do the culling in either system. One way to do it would be by inserting nans in the x and y arrays (I am thinking in terms of numpy array-based algorithms), since nan is already supported in backends as a do-not-draw marker. This brings up the larger question of why we have "newstyle" (do transformation in backend) and oldstyle (transform before calling backend) at all, and whether we still need both. My guess is that we don't; by consistently using numpy arrays for x and y, and by using the transformation function that works with these arrays, we should be able to do the transform equally efficiently in the backend or earlier. Making the backends consistent would take a bit of work, and perhaps some culling of backends that are neither widely used nor actively maintained. Eric