2010/3/29 Vangelis Katsikaros <vkatsikaros@...1244...>:
Hello
I have briefly described in the past my thoughts on how the render can be improved by introducing spatial indexes.
The render has to find which shapes intersect with the user's viewport. Currently this is done by a full scan in display/sp-canvas.cpp:871 in sp_canvas_group_render() right? (Krzysztof gave some hints in another thread some days ago).
Inkscape recurses into the canvas tree, and renders objects whose bounding box intersects the bounding box of the visible area of the currently rendered tile. In principle this leads to O(N) performance in the worst case, where N is the number of objects in the document. However, I don't think spatial indexing would improve things significantly - the majority of the time is spent rendering the visible items rather than skipping the invisible ones.
A better idea might be to use spatial indexing for determining which object is under the cursor (nr_arena_shape_pick) - this task takes about 20% of time on each motion event on complex drawings.
- The index should be disk based (so that it can be saved and reused
when Inkscape opens the same file again)
I don't think it's a good idea: 1. It will enlarge the SVG file. 2. The overhead of parsing the index data might be higher than creating it from scratch. 3. What if someone edits the SVG in some other editor and the index data goes out of sync with document contents?
- There should be a way to identify the shapes of the SVG uniquely
(either XML elements or elements from another abstraction Inkscape uses). Can anyone give me some pointers on how I should work for this issue?
Spatial indexing should be done at the SP layer (e.g. sp-path.cpp, sp-image.cpp, sp-item-group.cpp, etc.) or at the rendering layer (NRArenaShape et al); it definitely should not be done at the XML layer.
Regards, Krzysztof