On 7/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> First, I noticed a bug in the version I sent before. I've attached a new
> version in patch form, to be applied from the base directory of a normal
> 0.90.1 installation with 'patch -p1 <patch'.
Thanks Allan, I just applied this to svn. Some time ago I made an
optimization to Agg's draw_markers to used cached rasters of the
markers and this made a dramatic difference in speed. So it is nice
to complement that with this draw_lines optimization.
I was curious to see what approach you took to cull the points outside
the window -- just looking at the vertices of the current point and
last point and dropping if both are outside the x and y interval of
the viewport. As you mention in the comment, we could do a line
segment/rectangle intersection test to cull more, but it is not clear
that that would be faster because of the tradeoff between the cost of
the test and cost of drawing segments we don't need.
I wonder if you cached some of the interval tests whether you might
see some additional speedups. Eg, something like
thisoutsidex = (thisx<0 || thisx>width)
thisoutsidey = (thisy<0 || thisy>height)
if (thisoutsidex && thisoutsidey && lastoutsidex && lastoutsidey) {
// other stuff as necessary...
lastoutsidex = thisoutsidex
lastoutsidey = thisoutsidey
continue;
}
lastoutsidex = thisoutsidex
lastoutsidey = thisoutsidey
I suspect the comparisons are pretty cheap so I don't know how much
this will save but it might be worth looking into.
There is one case where your culling algorithm will fail, I think
view window x2
-----------------------------
| |
| |
| |
_______________
x1
The segment connecting x1 and x2 will be dropped, but the user should
see a line here, right? If we could do a rectangle/line intersection
test w/o giving up too much in terms of performance, that would be
better I think. That or give users the ability to turn it off. Since
people use mpl to view their scientific data, we should be careful to
make sure they can see it....
> One artifact I can clearly see is there is partly due to skipping lines <
> 1 pixel in length. The original agg renderer did this too, so it is not
> too different from before. My patch makes it worse, though. You can see it
> with plot(rand(10000)) again, but zoom out on only the y axis until the
> data is almost a straight line from right to left. You should see little
> clumps appear as it gets close to a straight line.
>
> Besides this I have not noticed anything. There may be problem cases I
> have not thought of, of course. To see the kind of problem that might
> occur, you can try changing the distance cutoff from 0.25 to something
> huge like 25.0. There you will definitely notice errors.
Do you think it is worth making this a line property so users can
tweak it? There are a couple of ways to get the line property
information into the backend -- the typical way is
to make a corresponding graphics context property and then set it in
the line draw method.
> About doing this for other image formats: I think it is OK for pixel-based
> images, but probably not for SVG or vector-based images. I can imagine
> someone writing to an SVG so that they can use another program to make a
> pretty rendering of it, but if lines are missing this second program does
> not have the full data to work with.
I do think it would be nice to support culling points outside the
viewport across backends. A recurring criticism is that our
postscript files with lots of points, in which the zoom is set to just
a subset of points, are quite large because we use graphics clipping
to get rid of them but the data are still in the file. As you note,
this can be a good thing for users who want to do post-hoc editing,
and culling is tricky because, for example, a point whose center is
outside the viewport could have a edge vertex inside the viewport. So
we would need polygon intersections to do it right (and even this
would not completely solve the case of polygons with thick edge
strokes) but having the option to cull points whose centers fell
outside the viewport, or line segments whose vertices fell outside the
x and y intervals, would be a big win in most common use cases.
Since we already support masks in the line class, probably the best
way to do this is would be some special purpose (possibly extension)
code that efficiently sets the mask. Then we would automatically get
support across backends.
JDH
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
