Re: nonlinear3.dem is very slow on aqua terminal

[Per P. <per...@ma...>]

(Away from computer, decade old code, etc., ...)

IIRC, I hesitantly added the erase rect code since some demo(?) relied on "overprinting" to erase previously drawn stuff, or possibly edge effect occurring when drawing multiple layers under anti-aliasing.

My guess is that taking out the call to erase rect is safe for 99.99% of the use cases.

That said, building an image using individual "pixels" is never going to be fast with the aqua terminal since it will create an object graph of all individual items so that the can be manipulated "post drawing". For speed, a better strategy is to create a bitmap image in the driver an push that as a unit to aquaterm. (Think that's how it's done elsewhere in the driver for som other command?)

Hope this helps,
Per


> 19 juli 2016 kl. 19:17 skrev Ethan A Merritt <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