Re: terrible canvas redraw behaviour - libart_lgpl is the culprit

[Paul Davis <pbd op net>]

[ Raph - the (Gnome|Gtk)Canvas objects suffer horribly when 
         asked to draw very large rects or lines that ought to
	 be simple to render. libart_lgpl seems to be the culprit.
]

I made a mistake in my last message about this. I forget that I was
still using horizontal lines on the Canvas that stretched from 0 to
(just) 100000.0

This is the culprit, in art_svp_render_aa.c:

		    /* case 2, antialias a run */
		    if (n_steps + ix_max + 2 - ix_min > n_steps_max)
		      {
			do
			  n_steps_max <<= 1;
			while (n_steps + ix_max + 2 - ix_min > n_steps_max);
			steps = art_renew (steps, ArtSVPRenderAAStep,
					   n_steps_max);
		      }

take the simple case of the line mentioned. we end up with ix_max =
99999, ix_min = -1, n_steps = 0 and n_steps_max initialized to 256.
we therefore bump n_steps_max to 131072 before the steps array is large
enough to contain the steps "required". then we call realloc() on 1MB
of data. 

whats wrong with this is that the code is attempting to render the
entire line. ix_max and ix_min should be somehow bounded by the area
of the RGB buffer that is being rendered, but instead represent the
entire object.

additionally, as the line length grows, the size of the realloc()
request grows, to the point where it fails, `steps' is set to NULL,
and the program segfaults.

i can see how to fix this for the straight line case, but i am not so
sure that it will work for other lines, so your comments and insight
are welcome.

--p