This guy on StackOverflow has a fairly good question on motion detection in wxPython: http://stackoverflow.com/questions/10849294/why-is-wxpythons-motion-detection-so-slow
Sadly, my skills in that area weren’t up to the task of answering the question, so I’m giving it to you guys.
Hi Mike,
Especially with performance, it’s important to know what else the app is doing besides tracking the mouse. The poster only showed what his on_motion handler is doing, not what he’s using that information for, which likely includes some form of drawing. It’s highly unlikely that firing an event alone takes almost half a second.
The typical issues I see with this sort of code are: repainting whether something changed or not, repainting the entire window instead of the one line that changes (i.e. using Refresh instead of RefreshRect), or calling Update repeatedly. But again, without knowing what the app is actually doing, it’s impossible to say where the real problem lies.
Regards,
Kevin
On Jun 8, 2012, at 10:58 AM, Mike Driscoll wrote:
This guy on StackOverflow has a fairly good question on motion detection in wxPython: http://stackoverflow.com/questions/10849294/why-is-wxpythons-motion-detection-so-slow
Sadly, my skills in that area weren’t up to the task of answering the question, so I’m giving it to you guys.
- Mike
–
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en
Hi Kevin,
On Fri, Jun 8, 2012 at 1:42 PM, Kevin Ollivier kevin-lists@theolliviers.com wrote:
Hi Mike,
Especially with performance, it’s important to know what else the app is doing besides tracking the mouse. The poster only showed what his on_motion handler is doing, not what he’s using that information for, which likely includes some form of drawing. It’s highly unlikely that firing an event alone takes almost half a second.
The typical issues I see with this sort of code are: repainting whether something changed or not, repainting the entire window instead of the one line that changes (i.e. using Refresh instead of RefreshRect), or calling Update repeatedly. But again, without knowing what the app is actually doing, it’s impossible to say where the real problem lies.
Regards,
Kevin
I didn’t think it sounded like normal wx behavior. I figured he HAD to be doing something else, but he hasn’t communicated what else he’s doing. I’ll ask on there and maybe get some clarification. Thanks!
Mike Driscoll
Hi Kevin,
Hi Mike,
Especially with performance, it’s important to know what else the app is doing besides tracking the mouse. The poster only showed what his on_motion handler is doing, not what he’s using that information for, which likely includes some form of drawing. It’s highly unlikely that firing an event alone takes almost half a second.
The typical issues I see with this sort of code are: repainting whether something changed or not, repainting the entire window instead of the one line that changes (i.e. using Refresh instead of RefreshRect), or calling Update repeatedly. But again, without knowing what the app is actually doing, it’s impossible to say where the real problem lies.
Regards,
Kevin
I didn’t think it sounded like normal wx behavior. I figured he HAD to be doing something else, but he hasn’t communicated what else he’s doing. I’ll ask on there and maybe get some clarification. Thanks!
Mike Driscoll
I had similar issues with an app as well, only to figure in the end that I had some other class constantly polling and thus updating canvas and repainting parts of my layout …
I suggest making him post a working mininmal example - very often this already clarifies things in the process …
Von meinem iPad gesendet
Am 08.06.2012 um 21:00 schrieb Mike Driscoll mike@pythonlibrary.org:
On Fri, Jun 8, 2012 at 1:42 PM, Kevin Ollivier kevin-lists@theolliviers.com wrote:
Cheers–
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en