Drawing speed

[Scott Raney]

On Fri, 22 Feb 2002 Jim Hurley <jphurley at jps.net> wrote:
> Subject: Drawing speed
> Reply-To: use-revolution at lists.runrev.com
> 
> 
> Jim Hurley wrote:
> 
> >  > > There appears to be no remedy in the offing to the speed problem.
> 
> Scott Rainey wrote:
> 
> >Actually the current release is pretty close to HC in performance,
> >the primary remaining difference being due to running in color vs
> >black and white (anywhere from 8 to 32 times as much data to move
> >around, you know).
> 
> I concede the difficulties in speedily running color vs. black and 
> white, and the improvement in the current release is much 
> appreciated. However there remains a considerable gap between MC/RR 
> and HC. For example, the following script draws concentric boxes of 
> ever decreasing size.
> 
> on mouseUp
>    clean
>    put 100 into a
>    put  300 into b
>    put 2 into da
>    choose the line tool
>    put the ticks into startTime
>    repeat 50 --draw boxes of ever decreasing size
>      drag from a,a to b,a
>      drag from b,a to b,b
>      drag from b,b to a,b
>      drag from a,b to a,a
>      add da to a
>      subtract da from b
>    end repeat
>    put the ticks - startTime into field 1
>    choose the browse tool
> end mouseUp
> 
> on clean
>    repeat until the number of images = 0
>      delete image 1
>    end repeat
> end clean
> 
> This script takes 265 ticks on average in RR and  30 ticks in HC on 
> cards of identical size.

Hmm, looks to be about a factor of 8, which is pretty good considering
there's about 32 times as much data being moved around (assuming
you're running in "millions" screen depth).  Further confirmation that
the limit is just with the data size is to increase (or decrease) the
size of the window or image: doubling it in width and height increases
the time by just about a factor of 4, demonstrating that all the time
is in moving the bits around.

> (I realize that this can be done more 
> efficiently with the rectangle tool and that a graphic would be 
> faster than an image. My  purpose was to measure the drag speed. ) 
> The discrepancy would be less in Windows.

Much less, actually.  I get 16 ticks on my 733MHz PIII.  We don't know
why masked image drawing is so slow on MacOS (hell, it's slow even
compared with UNIX/X11 which doesn't even *have* a masked image
drawing primitive and it has to be done with 3 separate operations
there), but unfortunately there's not a damned thing we can do about
it.

> There is no limit to the greedy demands which we, the  users, put on 
> Scott and the development team. In my case, to properly implement 
> Turtle Graphics, I hunger for a speedy monochromatic drawing  mode.

Unfortunately that's not the business we're in, and I doubt even that
would be a satisfactory solution to the problem even if we were (i.e.,
even the various Logo implementations all support color now).  But
this is the perfect situation in which to use an external.  You could
probably get 2 orders of magnitude better performance if you just drew
directly to the window instead of having everything buffered like
painting in HC and MC require.  You do lose the ability to overlay
images on buttons and fields, persistence, and the ability to edit the
bits you've previously drawn, but fortunately none of these things are
required for turtle graphics.  You might try M. Uli Kusterer's
(Witness.of.TeachText at gmx.net) xDraw package, for example, or ask him
if he has other suggestions for how best to do this.
  Regards,
    Scott

> Jim Hurley

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...