Re: nonlinear3.dem is very slow on aqua terminal

[Ethan A M. <sf...@us...>]

Brief summary:

The command "plot <foo> with image pixels" tells gnuplot to render
individual pixels rather than sending a bitmap of the entire image.
This has a number of uses.  The current bug report comes from demo
nonlinear3.dem, in which pixels must be rendered individually because
they are not of uniform size.

Bug:  This demo is horribly slow (8 minutes) using the aqua terminal


On Tuesday, 19 July, 2016 22:18:09 Jun T. wrote:
> 
> I did some profiling, and has found that gnuplot uses lots of CPU time at
> 
>   [adapter eraseRect:scaledRect];	aquaterm.trm, line 662                                   
> 
> and Aquaterm.app spends most of the CPU time processing these eraseRect
> requests from gnuplot.
> 
> AQUA_filled_polygon() does not (can not) have this eraseRect call, so it
> is not slow.
> 
> If I comment out the line 662 of aquaterm.trm, then nonlinear3.dem takes
> about 8 to 10 seconds (instead of 8 minutes), and it *seems* to give
> the same plot. But I guess eraseRect has been added intentionally to get
> better results in some cases, and rather hesitate to remove this line.
> 
> Another possibility is to include TERM_POLYGON_PIXELS in term->flags of
> aqua terminal. I also tried this, and it was virtually as fast as
> removing the line 662.
> Maybe this would be safe enough? TERM_POLYGON_PIXELS is not used other
> than at line 4977 of graphics.c.

It is fine to set set TERM_POLYGON_PIXELS.  That flag is an advisory to
the core code that the term->filled_polygon() routine is prefered to the
term->boxfill() routine for whatever reason.  In this case the reason is
execution speed.

I do not know why the aqua boxfill() routine calls eraseRect.
Other terminals do not have an equivalent call.
Perhaps the original author remembers why
	(cc-ed to Per Persson)

For now I will add the TERM_POLYGON_PIXELS flag, but it would be nice to
fix/improve AQUA_boxfill() also.

> 
> NOTE:
> I *guess* the eraseRect is slow due to the following reason. Suppose there
> is already a rectangle R0 with 4 corners at (0,0)-(0,100)-(100,100)-(100,0).
> If eraseRect is called with a rectangle Rx=(50,50)-(50,150)-(150,150)-(150,50)
> then it needs to modify R0 into a polygon with 6 vertices at
> (0,0)-(100,0)-(100,50)-(50,50)_(50,100)-(0,100).
> If there are many rectangles/polygons already in the plot, then eraseRect
> must find *all* the intersections of these pre-existing rectangles/polygons
> with the rectangle Rx.

	Ethan