Re: terrible canvas redraw behaviour - libart_lgpl is the culprit

[Raph Levien <raph levien com>]

On Thu, Sep 27, 2001 at 10:51:51PM -0400, Paul Davis wrote:
> [ 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.

I think you'll find this is fixed in CVS, along with a substantial
performance improvement.

You'll see another nice performance improvement, as well as increase
in robustness, when I get the new intersector working properly.

Thanks for your input - it helped greatly in diagnosing another
bug as well.

Raph