Benjamin Jessup wrote:
large. You are correct that this only becomes a problem if we want the objects to be 'hit-able' and there are more than ~10,000 of them.
good -- I did some testing with a modifies "Hexagons" demo (enclosed), and it did look like the caching was working correctly.
However, the hit test code is also caching the pens/brushes, and it does require that each object have a unique color, so yes, you get a lot of objects cached -- it doesn't create a problem on my OS-X box, but I see how it would on Windows.
Here is the solution I ended up with for hit testing without using a color map (using the bounding box of the object) :# Custom Hit Test Function to Replace FloatCanvas.HitTest def HitTest(self, event, HitEvent): if self.HitDict: # check if there are any objects in the dict for this event xy = event.GetPosition() xy = self.PixelToWorld( xy ) for key in self.HitDict.keys(): for key2 in self.HitDict[key].keys(): bb = self.HitDict[key][key2].BoundingBoxif xy[0] > bb[0,0] and xy[0] < bb[1,0] and xy[1] < bb[1,1] and xy[1] > bb[0,1]:print 'Hit Found1' Object = self.HitDict[key][key2] ## Add the hit coords to the Object Object.HitCoords = self.PixelToWorld( xy ) Object.HitCoordsPixel = xy Object.CallBackFuncs[HitEvent](Object) print 'Hit Found2' return True return False For the MouseOverTest I modified it to contain a similar loop.
looks good. I don't know if you looked, but it turns out that the Bounding Box object (in Utilities.BBox) doesn't have a "point is in the BBox" method, which is certainly should -- I'll add that!
I have found that the performance is nearly identical on my Core Duo [email protected] (2 GIG RAM) for up to 30,000 to 40,000 objects.
Interesting -- I'm surprised -- there is far more calculation going on there -- but I guess you can do a lot of calculations when a processor is doing over a billion computations a second.
Redrawing
the canvas with this many items is the limiting factor
And not drawing the hit-test bitmap is going to speed up drawing.The problem here is that being in the bounding box is only a hit for simple objects (technically, only rectangles), so it's pretty limited -- but you could do further checking after the BB check if you want.
I could speed this up to facilitate mouse over responses by indexingitems in a grid
I'm not quite sure what you mean, but the generic way to make this work well is to use a spatial index -- quad-tree or r-tree -- I've had that in mind for ages...
the most important thing for my application is that it doesn't fail as objects get added to the workspace.
yup -- that's key.
It could very well be caching the brush and pens for the dispaly bitmap. I don't think so.
The color map requires that we have a different pen and brush for each hit-able object, and whether or not they are cached can't make a difference since it doesn't reduce the set.
I don't think wx is caching, thought I'll test that at some point.
Also, your link: [ http://msdn.microsoft.com/en-us/library/ms724291(VS.85 <http://msdn.microsoft.com/en-us/library/ms724291%28VS.85>).aspx ] doesn't appear to be working.
hmm -- I got it by googling "GDI object limit XP": it's the first hit.Thanks for the report and the fix -- I hope I can come up with a general way to make this work.
-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 [email protected]
Hexagons.py
Description: application/python
_______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
