On performance

wxPython Users
1

Hello,
    my name is Pablo and I'm writing from Argentina. Right now I'm
coding a little application for some course I'm doing.

The course is on Computer Graphics. We were asked to write algorithms to
draw line segments and polygons, and to create the structure that is
necessary to achieve scenes, with transformations. I know this probably
won't make much sense to you, but we were asked to use wxWidgets.

Since I always liked Python, I said I'd like to do it using Python
instead of C++, and that was ok to them. So we used wxPython.

Thing is that right now we've showed the professor our first version. He
liked it, and he asked us to make some changes and add a few features.

In this program, I'm doing animations. Basically, I have a wx.Timer that
draws the new frame each time. To achieve better performance, I write
the pixels into a PIL Image, then convert it to a bitmap, and then show
it using wx.PaintDC's DrawBitmap() method.

I think I'm pushing the timer to its limits (I'm using 1 as the
parameter to Start()) and the animation is a little slow. I'm wondering
whether I could make the performance a little better.

Is there a faster way to create/show a bitmap?

Please, understand that we're not allowed to use things like DrawLine();
we're supposed to implement our own line drawing functions. We can only
use functions to write pixels into a bitmap, or a DrawPoint() function.

You can see the project here: http://code.google.com/p/cg-pm-2009/

Any help will be greatly appreciated.

···

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

2

Pablo Antonio wrote:

Hello,
    my name is Pablo and I'm writing from Argentina. Right now I'm
coding a little application for some course I'm doing.

The course is on Computer Graphics. We were asked to write algorithms to
draw line segments and polygons, and to create the structure that is
necessary to achieve scenes, with transformations. I know this probably
won't make much sense to you, but we were asked to use wxWidgets.

Since I always liked Python, I said I'd like to do it using Python
instead of C++, and that was ok to them. So we used wxPython.

Thing is that right now we've showed the professor our first version. He
liked it, and he asked us to make some changes and add a few features.

In this program, I'm doing animations. Basically, I have a wx.Timer that
draws the new frame each time. To achieve better performance, I write
the pixels into a PIL Image, then convert it to a bitmap, and then show
it using wx.PaintDC's DrawBitmap() method.

I think I'm pushing the timer to its limits (I'm using 1 as the
parameter to Start()) and the animation is a little slow. I'm wondering
whether I could make the performance a little better.

Is there a faster way to create/show a bitmap?

Please, understand that we're not allowed to use things like DrawLine();
we're supposed to implement our own line drawing functions. We can only
use functions to write pixels into a bitmap, or a DrawPoint() function.

You can see the project here: http://code.google.com/p/cg-pm-2009/

Any help will be greatly appreciated.

It's probably too late for this, but you should probably use pygame, pyglet or pyOpenGL for this sort of thing. At the very least, you can look at the source and see how they do it and then design your own blitting algorithms or whatever. Here's a few links:

http://www.pygame.org/docs/index.html

http://pyopengl.sourceforge.net/

You might be able to get some ideas from wxPython's wx.AnimateCtrl or Barker's float canvas:

http://morticia.cs.dal.ca/FloatCanvas/
http://wiki.wxpython.org/FloatCanvas

···

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

3

Pablo Antonio wrote:

Hello,
    my name is Pablo and I'm writing from Argentina. Right now I'm
coding a little application for some course I'm doing.

The course is on Computer Graphics. We were asked to write algorithms to
draw line segments and polygons, and to create the structure that is
necessary to achieve scenes, with transformations. I know this probably
won't make much sense to you, but we were asked to use wxWidgets.

Since I always liked Python, I said I'd like to do it using Python
instead of C++, and that was ok to them. So we used wxPython.

Thing is that right now we've showed the professor our first version. He
liked it, and he asked us to make some changes and add a few features.

In this program, I'm doing animations. Basically, I have a wx.Timer that
draws the new frame each time. To achieve better performance, I write
the pixels into a PIL Image, then convert it to a bitmap, and then show
it using wx.PaintDC's DrawBitmap() method.

I think I'm pushing the timer to its limits (I'm using 1 as the
parameter to Start()) and the animation is a little slow. I'm wondering
whether I could make the performance a little better.

Is there a faster way to create/show a bitmap?

The conversion from a PIL image to wx.Image and then to wx.Bitmap is very expensive so that is probably the best place to focus for performance improvements. It's now possible to have direct access to a wx.Bitmap's pixel buffer, although because of the overhead of transitioning to/from Python/C++ it's not very efficient to do it for every pixel. See the RawBitmapAccess sample in the demo.

Perhaps the best approach would be to manipulate the pixel data in some object that supports the buffer interface (like a NumPy array) and then convert it to a wx.Bitmap using one of the BitmapFromBuffer functions or wx.Bitmap.CopyFromBuffer. There are also some examples in the demo for this to help give you a starting point.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Hi Pablo,

Hello,
   my name is Pablo and I'm writing from Argentina. Right now I'm
coding a little application for some course I'm doing.

The course is on Computer Graphics. We were asked to write algorithms to
draw line segments and polygons, and to create the structure that is
necessary to achieve scenes, with transformations. I know this probably
won't make much sense to you, but we were asked to use wxWidgets.

Since I always liked Python, I said I'd like to do it using Python
instead of C++, and that was ok to them. So we used wxPython.

Thing is that right now we've showed the professor our first version. He
liked it, and he asked us to make some changes and add a few features.

In this program, I'm doing animations. Basically, I have a wx.Timer that
draws the new frame each time. To achieve better performance, I write
the pixels into a PIL Image, then convert it to a bitmap, and then show
it using wx.PaintDC's DrawBitmap() method.

I think I'm pushing the timer to its limits (I'm using 1 as the
parameter to Start()) and the animation is a little slow. I'm wondering
whether I could make the performance a little better.

Robin's suggestions are good ones, but I also want to point out that it's a common misperception that when animating, you want the drawing to refresh as fast as possible. You should not use 1 millisecond as your animation rate, because then you're redrawing far more times than the monitor is even capable of displaying. For example, a monitor with a 60 Hz refresh rate refreshes the screen 60 times per second, so that monitor is only capable of displaying animation at a rate of 60 fps. You're redrawing 1000 fps, and 1000 - 60 = 940, meaning 940 of those redraws won't even be seen by the user. Even with a 100Hz monitor, 9 / 10 of your draws are never even drawn to the screen, so you're just eating CPU time that is better served on other tasks.

A timer rate of ~10 ms should be enough to maximize your animation speed while minimizing unnecessary redraws.

Regards,

Kevin

···

On Apr 17, 2009, at 1:13 AM, Pablo Antonio wrote:

Is there a faster way to create/show a bitmap?

Please, understand that we're not allowed to use things like DrawLine();
we're supposed to implement our own line drawing functions. We can only
use functions to write pixels into a bitmap, or a DrawPoint() function.

You can see the project here: http://code.google.com/p/cg-pm-2009/

Any help will be greatly appreciated.

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

5

Kevin Ollivier wrote:

Robin's suggestions are good ones, but I also want to point out that it's a common misperception that when animating, you want the drawing to refresh as fast as possible. You should not use 1 millisecond as your animation rate, because then you're redrawing far more times than the monitor is even capable of displaying. For example, a monitor with a 60 Hz refresh rate refreshes the screen 60 times per second, so that monitor is only capable of displaying animation at a rate of 60 fps. You're redrawing 1000 fps, and 1000 - 60 = 940, meaning 940 of those redraws won't even be seen by the user. Even with a 100Hz monitor, 9 / 10 of your draws are never even drawn to the screen, so you're just eating CPU time that is better served on other tasks.

Good point. Also, the average human eye can't distinguish more than about 30 fps.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

6

Robin Dunn <robin@alldunn.com> writes:

Perhaps the best approach would be to manipulate the pixel data in
some object that supports the buffer interface (like a NumPy array)
and then convert it to a wx.Bitmap using one of the BitmapFromBuffer
functions or wx.Bitmap.CopyFromBuffer. There are also some examples
in the demo for this to help give you a starting point.

Perhaps the OP might also investigate offloading the raw algorithm
implementations into an extension module, using say a simple raw
memory block as the pixel buffer, and the above to eventually blit it
into wxPython.

This assumes that a large part of the current overhead is in the raw
pixel manipulation, and not just overly aggressive refreshes (as
pointed out in other responses). But I have a feeling that per-pixel
operations implemented in Python are going to be relatively high
overhead however you do it, and given the task at hand is the core
algorithm implementations themselves I'm not sure how well it could be
offloaded to an existing extension module.

Implementation could be a simple single-file C module with the core
drawing operations, which is then accessed via ctypes. Or perhaps
even easier, using Cython to implement the module to provide a clean
interface back to wxPython objects.

The overall application is Python/wxPython, but the raw pixel buffer
manipulation (other than final blits) is down in C. Down at that
level, doing say DrawLine algorithm against a raw memory block in C,
probably adds little complexity over a Python implementation. And
Cython would provide for a very easy integration as it permits mixing
Python objects and native C data types in an implementation.

-- David

7

[snip]

It's probably too late for this, but you should probably use pygame,
pyglet or pyOpenGL for this sort of thing. At the very least, you can
look at the source and see how they do it and then design your own
blitting algorithms or whatever. Here's a few links:

Pygame Front Page — pygame v2.6.0 documentation
http://www.pyglet.org/
http://pyopengl.sourceforge.net/

Yeah. Thing is we're supposed to use wxWidgets (or wxPython, in my
case). As far as I'm concerned, pygame uses SDL. Don't know about the
other, but they pretty likely use some C/C++ library other than
wxWidgets behind.

You might be able to get some ideas from wxPython's wx.AnimateCtrl or
Barker's float canvas:

http://morticia.cs.dal.ca/FloatCanvas/
FloatCanvas - wxPyWiki

Thanks. I'll take a look at this.

···

On Fri, Apr 17, 2009 at 09:16:51AM -0500, Mike Driscoll wrote:

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

8

[snip]

The conversion from a PIL image to wx.Image and then to wx.Bitmap is
very expensive so that is probably the best place to focus for
performance improvements. It's now possible to have direct access to a
wx.Bitmap's pixel buffer, although because of the overhead of
transitioning to/from Python/C++ it's not very efficient to do it for
every pixel. See the RawBitmapAccess sample in the demo.

Thanks for the input. I'm trying to use wx.NativePixelData() to access
an empty bitmap but it doesn't seem to work:

bmp = wx.EmptyBitmap(size[0], size[1], 32)

self.__px_data = wx.NativePixelData(bmp)
print wx.NativePixelData(bmp)
if not self.__px_data:
    raise RuntimeError("Error accessing the bitmap!")

The print gives something like:
<wx._gdi.NativePixelData; proxy of <Swig Object of type
'wxNativePixelData *' at 0xa09e930> >

but the exception is always raised. If I comment the if sentence (and
the line with the "raise", of course) I get a Segmentation Fault.

Am I doing anything wrong?

wx.VERSION

(2, 8, 8, 0, '')

That's the version I'm using.

Perhaps the best approach would be to manipulate the pixel data in some
object that supports the buffer interface (like a NumPy array) and then
convert it to a wx.Bitmap using one of the BitmapFromBuffer functions or
wx.Bitmap.CopyFromBuffer. There are also some examples in the demo for
this to help give you a starting point.

I'll take a look at this and let you know. Thanks.

···

On Fri, Apr 17, 2009 at 10:12:16AM -0700, Robin Dunn wrote:

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

9

I just did. I manipulated an array (from the "array" module) and then
used BitmapFromBuffer to conver the data to a bitmap, and it definitely
was a little slower than my old alternative (manipulating a PIL Image,
and then converting).

···

On Sat, Apr 18, 2009 at 03:12:24AM -0300, Pablo Antonio wrote:

On Fri, Apr 17, 2009 at 10:12:16AM -0700, Robin Dunn wrote:
>
> Perhaps the best approach would be to manipulate the pixel data in some
> object that supports the buffer interface (like a NumPy array) and then
> convert it to a wx.Bitmap using one of the BitmapFromBuffer functions or
> wx.Bitmap.CopyFromBuffer. There are also some examples in the demo for
> this to help give you a starting point.
>

I'll take a look at this and let you know. Thanks.

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

10

And now I tried the same but using numpy's array. It's slower too.

···

On Sat, Apr 18, 2009 at 03:30:33AM -0300, Pablo Antonio wrote:

On Sat, Apr 18, 2009 at 03:12:24AM -0300, Pablo Antonio wrote:
> On Fri, Apr 17, 2009 at 10:12:16AM -0700, Robin Dunn wrote:
> >
> > Perhaps the best approach would be to manipulate the pixel data in some
> > object that supports the buffer interface (like a NumPy array) and then
> > convert it to a wx.Bitmap using one of the BitmapFromBuffer functions or
> > wx.Bitmap.CopyFromBuffer. There are also some examples in the demo for
> > this to help give you a starting point.
> >
>
> I'll take a look at this and let you know. Thanks.

I just did. I manipulated an array (from the "array" module) and then
used BitmapFromBuffer to conver the data to a bitmap, and it definitely
was a little slower than my old alternative (manipulating a PIL Image,
and then converting).

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

11

Robin Dunn <robin@alldunn.com> writes:

> Perhaps the best approach would be to manipulate the pixel data in
> some object that supports the buffer interface (like a NumPy array)
> and then convert it to a wx.Bitmap using one of the BitmapFromBuffer
> functions or wx.Bitmap.CopyFromBuffer. There are also some examples
> in the demo for this to help give you a starting point.

Perhaps the OP might also investigate offloading the raw algorithm
implementations into an extension module, using say a simple raw
memory block as the pixel buffer, and the above to eventually blit it
into wxPython.

This assumes that a large part of the current overhead is in the raw
pixel manipulation, and not just overly aggressive refreshes (as
pointed out in other responses). But I have a feeling that per-pixel
operations implemented in Python are going to be relatively high
overhead however you do it, and given the task at hand is the core
algorithm implementations themselves I'm not sure how well it could be
offloaded to an existing extension module.

As you say, David, I don't think aggressive refreshes are the problem.
Maybe it's true that refreshing more times than my eyes see and my
monitor can display is stupid, but it certainly is not affecting
performance so much.

Implementation could be a simple single-file C module with the core
drawing operations, which is then accessed via ctypes. Or perhaps
even easier, using Cython to implement the module to provide a clean
interface back to wxPython objects.

The overall application is Python/wxPython, but the raw pixel buffer
manipulation (other than final blits) is down in C. Down at that
level, doing say DrawLine algorithm against a raw memory block in C,
probably adds little complexity over a Python implementation. And
Cython would provide for a very easy integration as it permits mixing
Python objects and native C data types in an implementation.

That sounds like a good solution, but also sounds like it's too much
work. I just don't think this little application deserves it. But it can
be a good idea for any future project.

Thanks.

···

On Fri, Apr 17, 2009 at 06:23:27PM -0400, David Bolen wrote:

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

12

Hi Pablo,

Hi!

[snip]

Robin's suggestions are good ones, but I also want to point out that
it's a common misperception that when animating, you want the drawing to
refresh as fast as possible. You should not use 1 millisecond as your
animation rate, because then you're redrawing far more times than the
monitor is even capable of displaying. For example, a monitor with a 60
Hz refresh rate refreshes the screen 60 times per second, so that
monitor is only capable of displaying animation at a rate of 60 fps.
You're redrawing 1000 fps, and 1000 - 60 = 940, meaning 940 of those
redraws won't even be seen by the user. Even with a 100Hz monitor, 9 /
10 of your draws are never even drawn to the screen, so you're just
eating CPU time that is better served on other tasks.

I agree that refreshing every 1ms has little sense, but I don't think
this is affecting performance here, as I said in a recent reply.

If you make the timer's refresh rate a little slower, the animation
doesn't get any faster. I think the timer does something like:

1. if possible:
2. call function
3. else:
4. wait until it's possible (i.e. the function isn't still running)
5. call function
6. go to 1 if the required time has passed

Thanks for replying.

···

On Fri, Apr 17, 2009 at 11:06:17AM -0700, Kevin Ollivier wrote:

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

13

Hi Pablo,

Hi Pablo,

Hi!

[snip]

Robin's suggestions are good ones, but I also want to point out that
it's a common misperception that when animating, you want the drawing to
refresh as fast as possible. You should not use 1 millisecond as your
animation rate, because then you're redrawing far more times than the
monitor is even capable of displaying. For example, a monitor with a 60
Hz refresh rate refreshes the screen 60 times per second, so that
monitor is only capable of displaying animation at a rate of 60 fps.
You're redrawing 1000 fps, and 1000 - 60 = 940, meaning 940 of those
redraws won't even be seen by the user. Even with a 100Hz monitor, 9 /
10 of your draws are never even drawn to the screen, so you're just
eating CPU time that is better served on other tasks.

I agree that refreshing every 1ms has little sense, but I don't think
this is affecting performance here, as I said in a recent reply.

When you say "you don't think", do you mean that you tried it, or that you're just assuming because you don't see a reason for it? Because when I said it's a "common misperception", I mean you're not the first person to have done this and have problems. :wink:

If you make the timer's refresh rate a little slower, the animation
doesn't get any faster. I think the timer does something like:

1. if possible:
2. call function
3. else:
4. wait until it's possible (i.e. the function isn't still running)
5. call function
6. go to 1 if the required time has passed

You're basically right, but you're forgetting something very important about step 4 - you're running on a multitasking OS. The OS queues events, and so you're adding up to 1000 events per second to the event queue. Moreover, the OS also has other apps and services asking for CPU time, so it has to figure out how to keep everything running while at the same time effectively letting you monopolize the CPU, an impossible task. I suspect actually that the OSes task scheduler just trying to figure out what tasks should run when is what is slowing everything down.

Anyway, if you're so sure it won't matter, then just go ahead and change the timer to fire at 15ms (or maybe 30ms if it requires a lot of CPU time), and then you can come back and tell me how the animation did not speed up at all. :wink:

Regards,

Kevin

···

On Apr 17, 2009, at 11:55 PM, Pablo Antonio wrote:

On Fri, Apr 17, 2009 at 11:06:17AM -0700, Kevin Ollivier wrote:

Thanks for replying.

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

14

Pablo Antonio <pabloa@gmail.com> writes:

That sounds like a good solution, but also sounds like it's too much
work. I just don't think this little application deserves it. But it can
be a good idea for any future project.

There will be some learning curve, but if you've got 30 minutes around
somewhere at least give Cython a quick check - you may be pleasantly
surprised at how easy it is to work into your existing project.

It does require that you can build extension modules on your machine
(e.g., have an appropriate compiler and what not), but since this is
for a course that would otherwise use C++ with wxWidgets, I'm
expecting that ought not to be a problem.

I suspect you can basically start your Cython module as nothing more
than your existing Python low level implementation code (complete with
all existing wxPython or PIL based objects), and then cherry pick a
few sections to optimize further in C, without calling code being any
the wiser other than having to import the Cython generated module.

-- David

15

Pablo Antonio wrote:

I just did. I manipulated an array (from the "array" module) and then
used BitmapFromBuffer to conver the data to a bitmap, and it definitely
was a little slower than my old alternative (manipulating a PIL Image,
and then converting).

And now I tried the same but using numpy's array. It's slower too.

I'm surprised -- is it slower to manipulate the array, or slower to convert and display?

Anyway, I suggest making a simple sample, showing your PIL code and numpy code, there may be things you could do better.

In general, numpy in general for this would probably be helpful, there may be many opportunities for performance gains.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (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

16

Uhmm... I took a look at this approach again; now using numpy.array. However,
I found a new problem: The bitmap is not rendered properly; it's like it's
repeated in a strange way four times horizontally.

Here's my code:

    # create the array
    self.__bytes = numpy.empty((width, height, 3), numpy.uint8)
    # make all the pixels white
    self.__bytes[:,:,:] = 255

    # the following line writes into the array, calling for each pixel that
    # I want to draw some putpixel function that looks like:
    # def putpixel(self, x, y, colour = (0, 0, 0)):
    # self.__bytes[x, y, 0] = colour[0]
    # self.__bytes[x, y, 1] = colour[1]
    # self.__bytes[x, y, 2] = colour[2]

    self.draw()

    # get the bitmap
    bmp = wx.BitmapFromBuffer(width, height, self.__bytes)

    # paint it
    pdc = wx.PaintDC(self)
    pdc.DrawBitmap(bmp, 0, 0)

Do you see anything wrong? Any suggestions?

Thanks in advance.

···

On Sat, Apr 18, 2009 at 03:30:33AM -0300, Pablo Antonio wrote:

On Sat, Apr 18, 2009 at 03:12:24AM -0300, Pablo Antonio wrote:
> On Fri, Apr 17, 2009 at 10:12:16AM -0700, Robin Dunn wrote:
> >
> > Perhaps the best approach would be to manipulate the pixel data in some
> > object that supports the buffer interface (like a NumPy array) and then
> > convert it to a wx.Bitmap using one of the BitmapFromBuffer functions or
> > wx.Bitmap.CopyFromBuffer. There are also some examples in the demo for
> > this to help give you a starting point.
> >
>
> I'll take a look at this and let you know. Thanks.

I just did. I manipulated an array (from the "array" module) and then
used BitmapFromBuffer to conver the data to a bitmap, and it definitely
was a little slower than my old alternative (manipulating a PIL Image,
and then converting).

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

17

[snip]

Uhmm... I took a look at this approach again; now using numpy.array. However,
I found a new problem: The bitmap is not rendered properly; it's like it's
repeated in a strange way four times horizontally.

Here's my code:

    # create the array
    self.__bytes = numpy.empty((width, height, 3), numpy.uint8)
    # make all the pixels white
    self.__bytes[:,:,:] = 255

    # the following line writes into the array, calling for each pixel that
    # I want to draw some putpixel function that looks like:
    # def putpixel(self, x, y, colour = (0, 0, 0)):
    # self.__bytes[x, y, 0] = colour[0]
    # self.__bytes[x, y, 1] = colour[1]
    # self.__bytes[x, y, 2] = colour[2]

    self.draw()

    # get the bitmap
    bmp = wx.BitmapFromBuffer(width, height, self.__bytes)

    # paint it
    pdc = wx.PaintDC(self)
    pdc.DrawBitmap(bmp, 0, 0)

Do you see anything wrong? Any suggestions?

Thanks in advance.

Doesn't matter. I found it myself. Thing is that, for some reason that I
have yet to know, the array has to be constructed with (height, width,
3) (notice that height is now the first index).

Thanks anyway.

···

On Tue, Apr 21, 2009 at 03:48:28AM -0300, Pablo Antonio wrote:

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

18

Here's the code of my implementations[1].

One creates a PIL Image, then puts pixels into it using Image.load()'s
buffer. Then converts it to a bmp.

The other creates a numpy array, puts the values corresponding to pixels
into it, then uses wx.BitmapFromBuffer() to create the bmp.

You can see for yourselves the first approach is faster. Just checkout
the project[2] from svn, and run main.py both with USE_NUMPY (in
core/windows.py) set to True and False. Be aware that you have to
uncomment the line which says "import numpy" in order to try the
implementation that uses numpy.

I don't quite understand why the first one is faster. Also, I'm thinking
on some optimizations I could do to both. I'm creating a new PIL Image
and a new array each time the frame is repainted (which happens every
time because it's an animation). Maybe I could save this structure
somewhere and reuse it to get better performance. What do you think?

[1]
http://code.google.com/p/cg-pm-2009/source/browse/trunk/TP1/src/quilombo/core/windows.py
[2] http://code.google.com/p/cg-pm-2009/source/checkout

···

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

19

Pablo Antonio wrote:
...

[1]
Google Code Archive - Long-term storage for Google Code Project Hosting.
[2] Google Code Archive - Long-term storage for Google Code Project Hosting.
  

When I run main.py I see tons of the following exception:
Traceback (most recent call last):
  File "C:\Dev\BoaTest04\PabloAntonio\TP1\src\quilombo\core\windows.py", line 72, in on_paint
    pdc = wx.PaintDC(self)
  File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_gdi.py", line 4781, in __init__
    _gdi_.PaintDC_swiginit(self,_gdi_.new_PaintDC(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ..\..\src\msw\dcclient.cpp(219) in wxPaintDC::wxPaintDC(): wxPaintDC may be created only in EVT_PAINT handler!

Windows Vista with:
# Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
# wxPython 2.8.9.1, Boa Constructor 0.6.1

Werner

20

Werner F. Bruhin wrote:

Pablo Antonio wrote:
...

[1]
Google Code Archive - Long-term storage for Google Code Project Hosting.

[2] Google Code Archive - Long-term storage for Google Code Project Hosting.
  

When I run main.py I see tons of the following exception:
Traceback (most recent call last):
File "C:\Dev\BoaTest04\PabloAntonio\TP1\src\quilombo\core\windows.py", line 72, in on_paint
   pdc = wx.PaintDC(self)
File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_gdi.py", line 4781, in __init__
   _gdi_.PaintDC_swiginit(self,_gdi_.new_PaintDC(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ..\..\src\msw\dcclient.cpp(219) in wxPaintDC::wxPaintDC(): wxPaintDC may be created only in EVT_PAINT handler!

I think this line is causing the problem
            self.Bind(wx.EVT_TIMER, self.on_paint, id=1)

If I change self.on_paint to a dummy method it runs without error.

Werner