In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot. Unless edges can be curved, a simple rect-rect intersection would be quite sufficient for eliminating lots of edges, at least in the zoomed in scenario.
It makes sense. Currently, all the non-embedded edges are displayed. However, if the window is not between the two extremity, then there is no point in drawing the edge. Something that I should implement. I added a google entry for this: http://code.google.com/p/moose-technology/issues/detail?id=450
What I meant was, even if you do culling at the object level, you're still iterating over the entire model deciding what should be rendered every displayOn: call (if only just to perform an isVisible: check).
Yes
What you really need (in _addition_ to the current graph-model, which works great for reporting damage rects etc when manipulating the model), is f.ex. a quad-tree structure based on the physical location of the objects, which can be used for culling during the rendering phase.
Yes, we have been talking about QuadTree recently. It would be great to have them in Mondrian. However, QuadTree will work well for rendering the nodes. One problem that prevent scalability, is the layout computation. It easily take a lot of time.
That, and, I just realized, drawing each visible object once. ;) If I'm not wrong (haven't tested it) the elementsToDisplay is created using allSubNodes/EdgesDo: , so what happens in the cases where displayOn: is called to one of the visible subnodes, which also has visible subnodes?
A subnode is removed from elementsToDisplay if its parent is displayed and uses a bitmap cache (in #updateOwner). Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.