|
From: Kevin A. <al...@se...> - 2001-09-15 20:09:17
|
I wanted to get an idea of what the overhead for the current plot routine,
wxPython, blitting from an offscreen bitmap, etc. These numbers are rough at
best, but I needed to get a feel for the relative speed of drawing using
Python/wxPython.
In all the tests, I plotted one million points into roughly the same window
area. The Java applet was something I wrote a long time ago using AWT and it
isn't optimized, so I'm sure it could be made somewhat faster. One important
point is that all the Java variables and calculations were done with doubles
for better precision, the current Python version suffers from precision
problems that could probably be improved by using NumPy. It would probably
be interesting to do a Jython version, but that's left an exercise for the
reader.
All tests done with an AMD 1.2GHz, GeForce 2MX, 512MB RAM, Windows 2000 SP2,
screen depth @ 16-bits, ActivePython 2.1.212, wxPython 2.3.1
time in (seconds) ops/sec drawing type
-----------------------------------------------------------------
4 250,000 Java applet using AWT
4 250,000 hopalong.py, calculation only
plot() commented out
19 52,632 hopalong.py, autoRefresh=0
30 33,333 turtle.py, hopalong.txt script
direct screen draws, no offscreen
118 8,475 hopalong.py, autoRefresh=1
1 pixel blit
868 1,152 hopalong.py, autoRefresh=1
full window blit
The drawing time might be dramatically slower for other machines, video
cards, Linux, etc. It is unlikely that wxWindows is optimized for DirectX,
so another interesting test would be the same drawing using PyGame which
uses SDL which is a sort of cross-platform DirectX clone.
There a few observations I can make from the numbers above. The drawing time
for a single operation even with a full window blit after each plot command
is fast enough that interactive drawing say in response to mouse movement is
probably not a problem. The only problem might be that the blit operation
needs to be synced with the vertical refresh of the display to prevent
flashing, which would be up to wxWindows and may not be possible on Linux.
Second, like almost all drawing operations, the calculation time is small,
the real limitation is the I/O, drawing to the screen. I'm actually
surprised at the overhead of drawing to an offscreen bitmap (wxMemoryDC) in
wxWindows. wxWindows does not currently provide much in the way of clipping
rect or regions to determine whether a point plot, line drawing, etc. needs
to be drawn. It might be worthwhile to actually do our own tests to avoid
drawing when it isn't necessary.
The drawing time will go up if the operation is threaded, uses Yield, etc.
so that the user interface can remain responsive during a long calculation.
See
http://wxpython.org/cgi-bin/wiki/LongRunningTasks
for more info about possible solutions we might incorporate. I think we need
to do this, since most of the drawing people will want to do will probably
be interactive in nature and not batched.
The last point is that considering the speed of the hardware the tests were
done on, the combination of Python and wxPython does not appear to be a good
solution for many types of graphics intensive applications. That isn't
surprising, but I don't think we should spend much time trying to address
that solution space. It will be possible to do simple 2D games.
ka
---
partial Java hopalong program
public int sign(double n) {
if (n < 0) { return -1; } else { return 1; }
}
public void plot(Graphics g, double x, double y) {
int x1, y1;
x1 = (int) Math.round(xOffset + scale * x);
y1 = (int) Math.round(yOffset + scale * y);
g.drawLine(x1, y1, x1, y1);
...
for (int i = 0; i < iterations; i++) {
temp = y - sign(x) * Math.sqrt(Math.abs(b * x - c));
y = a - x;
x = temp;
...
g.setColor(color);
plot(g, x, y);
}
|