Re: nonlinear3.dem is very slow on aqua terminal

[Jun T. <tak...@kb...>]

On 2016/07/19, at 15:29, Daniel J Sebald <dan...@ie...> wrote:
>> 
>> They don't use the 'pixels' option for plot.
> 
> That's true.  But they do use the same polygon code ultimately.

If 'pixels' is not specified, then process_image() calls AQUA_image(), while with
'pixels' it calls AQUA_boxfill(), which is very slow.

> How long does the following plot take?:
> 
> plot 'blutux.rgb' binary array=(128,128) flipy rotation=30d format='%uchar' with rgbimage

It takes just a few seconds.
As you know, AQUA_filled_polygon() is called in this case.


On 2016/07/19, at 16:28, Daniel J Sebald <dan...@ie...> wrote:
> Is there some way of undefining LOGGING and recompile?:

LOGGING is not defined by default.


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.

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.