Poor speed of wx.lib.plot

Besides the other suggestions you will find that drawing offscreen and then blitting the result is generally much faster than doing each draw operation on screen. Also, drawing speed is impacted dramatically by the type of video card you have. A decent 3D gaming video card will probably show little overhead in the actual drawing operations.

ka

···

On Aug 12, 2004, at 2:58 PM, Hubbard, Gary wrote:

Hi,

I regularly work with large, scientific, data sets that I need to plot. I
have looked into several existing packages, and have been very unhappy with
the speed of each of them. Upon more careful examination I have decided
that the entire problem must lie within the calls to dc.DrawLines().

Looking at wx.lib.plot, which would probably be a fine starting place for
me, the comments indicate that they got 0.078 s to draw a 25,000 point
vector. Modifying the code in draw4 to only draw zero width lines and no
markers, gave me about 0.400 sec on a relatively good computer (2.8 GHz P4).
Can anybody else reproduce anything like the indicated speed. I am running
Python 2.3.4, wxPython 2.5.1 under WinXP.

Without actually setting up to debug the C parts of wxPython, I have come to
the conclusion that the problem is probably almost entirely in the
translation of the passed wxPoint array into the C++ equivalent. I have a
numarray (1.0) array of integers, which is effectively the data already
laid out like the underlying C++ API eventually needs it, but the helper
routines go through a huge amount of work, ripping things apart one value at
a time and reconstructing them again. It seems like there should be a way
for wxPoint_LIST_helper to accept some sort of pre-constructed memory buffer
which is assumed to be properly built. For example, if the incoming data
type is a string assume that it is an array of integers x0, y0, x1, y1, ...
and use it directly.

If I am completely off base about where the time is being consumed this kind
of change might not help at all, but other than the Win32 layers itself I
can't see anything else that could explain it.

Gary

Kevin Altis wrote:

Besides the other suggestions you will find that drawing offscreen and then blitting the result is generally much faster than doing each draw operation on screen.

Really? I've never noticed this. I"ll have to do a test...

  Also, drawing speed is impacted dramatically by the

type of video card you have. A decent 3D gaming video card will probably show little overhead in the actual drawing operations.

yes, but in this case the OP is right, the delay he's seeing is the conversion from a numarray to the native format, not the drawing itself.

Another plan I have to is to write a separate extension that implements some special purpose drawing operations that take NumPy arrays as arguments. If anyone else wants to help me with this, we could make a general purpose add-on module for wxPython.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov