All I can say is that if you use CaptureMouse then you better cover all eventualities because it can get nasty, basically a window manager restart on Linux. I finally gave up on CaptureMouse myself, it is just too evil and the behavior is wildly different across platforms. For safety you might want to consider releasing the mouse on idle if you get yourself into an unkown state during a mouse operation.
ka
···
On Mar 4, 2004, at 1:10 PM, Chris Barker wrote:
Robin Dunn wrote:
When I click and drag the mouse on GTK and Windows, it appears to be automatically captured by the window. THat is, I continue to get Motion events after the mouse leaves the window, and an up event when I release the mouse.
Eeek!!
Oh. I liked it that way, it seems natural to me.
On OS-X, the motion events stop when I leave the Window, and If I release the mouse whiole outside the window, I don't get hte up event. If I do a wx.Window.CaptureMouse() on the down event, and a ReleaseMouse() on the up event, it works fine
This is how all the platforms are supposed to work, and in my experience is how they did work in the past...
I'm pretty sure it hasn't worked that way on GTK for a LONG time
Are you sure it is not working correctly in Windows?
No, I'm not. I havn't tested on Windows in a while. All I know is that I never noticed that it worked differently on Windows than GTK, and when I Zoom and Scroll with the FloatCanvas, it really breaks things fast if the mouse isn't captured.
Adding the Capture code doesn't seem to break anything on GTK, so I"ve got a fix that works, and appears that is will continue to work after this bug is fixed on GTK.
All I can say is that if you use CaptureMouse then you better cover all eventualities because it can get nasty, basically a window manager restart on Linux. I finally gave up on CaptureMouse myself, it is just too evil and the behavior is wildly different across platforms. For safety you might want to consider releasing the mouse on idle if you get yourself into an unkown state during a mouse operation.
Well, it seems to work so far. I Capture the mouse on a left down (in some cases) and release it on a left up (always, if it's captured). This seems to work OK. It seems that I'll always have to have a left up event after I've captured the mouse. If you can see a possibel problem with this, let me know.
Without CaptureMouse, the problem is that if you are drawing a rubber band box to zoom in, for example, and you drag the mouse a little outside the window, and then let it go, I never get the mouse up that signifies the end of the operation. It works really naturally with CaptureMouse. Without it, I guess I'd ahve to track EnterWindow events, and check if the mosue was released, etc. What a pain.
As a note, I find a lot of the Mouse events too primitive anyway. At teh application level you want to be able to capture a drag, but wxPython doesn't provide a way to do that. You have to set a flag on the mouse-down, then check every single motion event to see if the button is down, then do something if the button is down, etc. It would be so much nicer to have a DragEvent of some sort.
-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
All I can say is that if you use CaptureMouse then you better cover all eventualities because it can get nasty, basically a window manager restart on Linux. I finally gave up on CaptureMouse myself, it is just too evil and the behavior is wildly different across platforms. For safety you might want to consider releasing the mouse on idle if you get yourself into an unkown state during a mouse operation.
Well, it seems to work so far. I Capture the mouse on a left down (in some cases) and release it on a left up (always, if it's captured). This seems to work OK. It seems that I'll always have to have a left up event after I've captured the mouse. If you can see a possibel problem with this, let me know.
Yes the explosion happens if you never get the mouse up. I can't remember the various ways that might happen, especially on Linux, but possibilities include moving the mouse outside your window onto another application that grabs the focus; that might only happen depending on the window manager settings. It has been a long time since I walked away from CaptureMouse, so maybe it just works these days. Your users will let you know soon enough
Without CaptureMouse, the problem is that if you are drawing a rubber band box to zoom in, for example, and you drag the mouse a little outside the window, and then let it go, I never get the mouse up that signifies the end of the operation. It works really naturally with CaptureMouse. Without it, I guess I'd ahve to track EnterWindow events, and check if the mosue was released, etc. What a pain.
As a note, I find a lot of the Mouse events too primitive anyway. At teh application level you want to be able to capture a drag, but wxPython doesn't provide a way to do that. You have to set a flag on the mouse-down, then check every single motion event to see if the button is down, then do something if the button is down, etc. It would be so much nicer to have a DragEvent of some sort.
Oh you mean like PythonCards' on_mouseDrag? It also has on_closeField which fires only when a field changes as opposed to just losing focus.
What are your current feelings about the DrawXXXList functions? Quite some time ago, I wrote the rest of them, so there is a fullset (I think) of DrawXXXList function. However, I did some testing and found that there isn't really a noticable performance impovement for any of the more complex objects.
I was most disappointed with DrawBitmapList. I tried to use it in wxPyPlot, so that you could draw a bitmap at each of the data points, rather than looping through and drawing a polygon (or whatever) at each point. I thought that it would surely be faster to blit a bitmap that draw a polygon. However, when I tested it, it was a little slower, rather than faster. Now that I've looked into how masked bitmaps work, I think the problem there was that it's very slow to draw a masked bitmap, period. It might work better without the mask. Perhaps that's worth a test.
Another issue for me is that, at least with my FloatCanvas, I am often zoomed in, and there is no need to draw everything anyway. I have sped things up a great deal in these cases, by checking the bounding boxes of the objects before drawing them, so I only draw what's required. If I need to speed this up more in the future, I plan to write a version of DrawXXXList, but with the Bounding box check and scaling and shifting all built in. This would be special purpose code, so it wouldn't belong in wxPython itself.
Anyway, the short version is: I'm only making use of DrawPointList, but if others want all the other methods, including ones that are not in the current version, I'd be glad to get the additional code working with 2.5, and send you patch.
What do you think?
-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
Well I'm making use of DrawPointList and DrawRectangleList and last time I checked it was worth using both, but I can do some comparisons if needed. Given the trickiness of benchmarking it might be hard to say where the real bottlenecks are, and results will vary depending on the type of video card you have. Drawing without blits between draw operations, using cached bitmaps rather than recreating them, etc. could obviously have a lot of impact. I'm in favor of keeping at least the simple DrawXXXList methods.
ka
···
On Mar 5, 2004, at 11:58 AM, Chris Barker wrote:
Robin,
What are your current feelings about the DrawXXXList functions? Quite some time ago, I wrote the rest of them, so there is a fullset (I think) of DrawXXXList function. However, I did some testing and found that there isn't really a noticable performance impovement for any of the more complex objects.
I was most disappointed with DrawBitmapList. I tried to use it in wxPyPlot, so that you could draw a bitmap at each of the data points, rather than looping through and drawing a polygon (or whatever) at each point. I thought that it would surely be faster to blit a bitmap that draw a polygon. However, when I tested it, it was a little slower, rather than faster. Now that I've looked into how masked bitmaps work, I think the problem there was that it's very slow to draw a masked bitmap, period. It might work better without the mask. Perhaps that's worth a test.
Another issue for me is that, at least with my FloatCanvas, I am often zoomed in, and there is no need to draw everything anyway. I have sped things up a great deal in these cases, by checking the bounding boxes of the objects before drawing them, so I only draw what's required. If I need to speed this up more in the future, I plan to write a version of DrawXXXList, but with the Bounding box check and scaling and shifting all built in. This would be special purpose code, so it wouldn't belong in wxPython itself.
Anyway, the short version is: I'm only making use of DrawPointList, but if others want all the other methods, including ones that are not in the current version, I'd be glad to get the additional code working with 2.5, and send you patch.
What are your current feelings about the DrawXXXList functions? Quite some time ago, I wrote the rest of them, so there is a fullset (I think) of DrawXXXList functions. However, I did some testing and found that there isn't really a noticable performance impovement for any of the more complex objects.
Well I'm making use of DrawPointList and DrawRectangleList and last time I checked it was worth using both, but I can do some comparisons if needed. Given the trickiness of benchmarking it might be hard to say where the real bottlenecks are, and results will vary depending on the type of video card you have.
Benchmarking has been a pain, particularly on GTK, because X is asynchronous. This means that simple timings just tell you how long it took to tell X what to draw, not to actually draw it. It's possible to run X (or a particular X client) in sync mode, but I never figured out how to do it.
Drawing without blits between draw operations, using cached bitmaps rather than recreating them, etc. could obviously have a lot of impact.
None of these have much to do with the DrawXXXList methods, however. Though you couldn't do a blit between drawing with these methods.
I'm in favor of keeping at least the simple DrawXXXList methods.
I wasn't proposing getting rid of them, the question was really to whether or not to add the rest of them. Honestly, my original motivation was to do them all for completeness sake, rather than for performance anyway.
Now that I've gone back to look at the code, it appears that I got further than I thought. It looks like it's in pretty good shape. Assuming that it ports to 2.5 fairly easily, I'm inclined to do it.
Robin--your thoughts?
-Chris
···
On Mar 5, 2004, at 11:58 AM, Chris Barker wrote:
--
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
I'm in favor of keeping at least the simple DrawXXXList methods.
I wasn't proposing getting rid of them, the question was really to whether or not to add the rest of them. Honestly, my original motivation was to do them all for completeness sake, rather than for performance anyway.
Now that I've gone back to look at the code, it appears that I got further than I thought. It looks like it's in pretty good shape. Assuming that it ports to 2.5 fairly easily, I'm inclined to do it.
Robin--your thoughts?
I don't mind adding more, but only if they are genuinely useful. If there is not much to be gained by the new methods then I think adding them just for the sake of completeness is not enough.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
