pyCard_turtleTimes

Kevin Altis altis at semi-retired.com
Fri Jul 12 23:12:53 EDT 2002


First of all, I'll make the assumption that the original poster is using
release 0.6.7 or what is in cvs, so there aren't any "old code" issues.

My apologies about the comments embedded in some of the scripts about
drawing times. Those comments are mostly over a year old prior to the turtle
sample being changed to use an offscreen bitmap for drawing, thus preserving
the bits drawn as the screen is refreshed, windows overlapped, etc. That
double-buffering becomes expensive during drawing because the present code
is forced to blit the entire bitmap to be safe. The problem is that if auto
refresh is enabled the entire bitmap is blitted on screen after each turtle
call which results in the worst possible performance when drawing a pixel at
a time. Depending in changes to the underlying wxWindows wxDC class, the
turtle class may get improved to get around this issue, but for now it is
better suited for interactive drawing from the shell or by turning off auto
refresh.

The later releases of PythonCard changed the drawing to support drawing
without refreshes on the turtle sample, so if Auto refresh is unchecked
under the Commands menu you should dramatically faster times. How dramatic?
Well I just ran Hopalong using the default 100,000 points of the
hopalong.txt script and got a time of 185 seconds, but if Auto Refresh is
unchecked the draw time drops to 5 seconds.

Mostly, I haven't bothered to go back and play with this because nobody has
ever expressed any interest in the turtle sample, thus there seemed to be
little reason to go spend time on it when I could be doing other things in
PythonCard that people are asking for.

Blitting the entire bitmap on screen is really expensive. That is why
plotting should really be done without using a turtle as the hopalong sample
shows. The turtle sample predates the hopalong sample which uses a different
algorithm for plotting and updating the screen. On the same machine, drawing
100,000 points with refreshes occurring as the color plotted changes, only
takes 1.5 seconds. So, 1.5 seconds instead of 185 seconds, which way do you
want to draw points? :)

All draw times should mostly be limited by the video card, but if your box
is low on memory that could have a major negative impact. I have a little
evidence that the exact same CPU, memory, and video card is faster on
Windows 2K/XP than Linux, which might be due to the quality of nVidia
drivers on Windows or might have something to do with GTK; I would like to
see more tests in this area. I don't use Linux, so this is based on seeing
drawing on other users boxes. I do know that the Mac OS X Quartz engine is
dramatically slower with this wxPython/PythonCard drawing stuff, apparently
blits are super expensive with the current Quartz engine as of 10.1, so none
of the turtle drawing is usable without turning off Auto Refresh and the
hopalong sample is pretty darn slow. It might be that all windows are
already buffered on OS X and that double-buffering is a waste with Quartz,
but I don't know of anyone that has dug into wxWindows wxDC behavior on OS X
deep enough to find out. I just know on my OS X box, the drawing is slow.

ka

"Neil Hodgson" <nhodgson at bigpond.net.au> wrote in message
news:Q5KX8.434157$o66.1173345 at news-server.bigpond.net.au...
> Cousin Stanley:
>
> > I'd be interested to know how other  machines/platforms  compare
> > for the ones that take the longest here ...
>
>     ChaosScript2and3 ..... 157
>     hopalong ......................  554
>     madness ...................... 482
>
> Its not a simple multiplier on your results, possibly due to different
> CPU:Video performance ratios on the two machines. I see a lot of variation
> in times with subsequent runs of ChaosScript2and3 taking 117 and 184
> seconds.
>
>   Cheap locally assembled box
>     Processor ... AMD Athlon 600
>     Memory ...... 384 MB
>     Video ........... NVIDIA RIVA TNT2 64
>
> Software
>
>   Window 2000
>   Python 2.2
>
>    Mmm, performance of these applications is so central to my efficiency
> that I must buy a better machine ;-)
>
>    Neil
>
>
>





More information about the Python-list mailing list