W dniu 24 marca 2010 15:29 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/3/23 Krzysztof Kosiński <tweenk.pl@...400...>:
- Currently there are actually two different canvas, with one drawing
into an item of the other: SPCanvas uses a special item, SPCanvasArena, to display an NRArena with all NRArenaItems. I think this could be unified and NRArena should be just a group.
I'm not sure it is a good idea. The canvas and arena being different classes is very logical (image itself vs. auxiliary editing aids) and practically useful (those that only need a rendition of SVG can only create an arena and never worry about the canvas with its tiling machinery). Yes, there's some similarity between them, but not much, and a lot more subtle differences that would be a nightmare to reconciliate.
I would solve this as follows:
1. The canvas defines some interfaces, e.g. Renderable, RenderableShape, RenderableImage, etc. These would define methods needed to render the thing. Renderable would have one method - render(), that would take a Cairo context and output it to the given Cairo context. RenderableShape would be a subclass of Renderable which implements the render() method for shapes, and instead has more specific methods like: Geom::PathVector getShape() Inkscape::Canvas::Paint getPaint() boost::shared_ptrInkscape::Canvas::Renderable getMask() Inkscape::Canvas::Filter getFilter()...
RenderableImage would have: Glib::RefPtrGdk::Pixbuf getPixbuf()
RenderableGroup would recurse into its children.
2. Those interfaces have various implementations: ones that are not bound to the XML, which work like current SPCanvasItems, and ones that do, which work like SPItems. This way we can maintain the CanvasItem / SPItem split while keeping the renderer oblivious of it, so that controls and SVG are rendered with he same high fidelity. (For example, right now control points are unaliased.)
3. Tiled rendering would be an option of the canvas widget; it's as simple as passing a different bounding box to render the root group.
- Every canvas and arena item can receive events. This is useful when
implementing control points, but not for much else, and causes some slowdown when there are many complex paths, because on nearly every motion event the item under the cursor needs to be recalculated. I recall that when I profiled for slowdown in the new node tool, there was a nontrivial amount of time spent in children of pick_item on motion events. While the node tool obviously needs to do this, other tools like the selector don't - they only need to find the item under cursor on clicks.
No, actually it tracks it all the time because it changes the cursor over selectable objects, via enter/leave signals.
I think it can be done using sp_event_context_find_item; this way picking the item under the cursor would be only done on demand.
- In case this project is too ambitious for GSoC, its scope can be
reduced so that NRArena rendering is converted to use Cairo operations. Right now graphics are rendered into NRPixblocks.
Exactly, this was always my idea for this project since the very start. I can be your mentor again :) I'm not much of a guru on rendering and rasterization as such, but I have spent quite some time in arena/canvas code.
I think some cleansing could be done simultaneously: 1. Get rid of NRObject. It's essentially an inferior clone of GType which is used inside NRArena. 2. Get rid of remaining NR geometry code. 3. Get rid of SPCurve and replace it with a shared copy-on-write Geom::PathVector (which should be renamed to Geom::PathSequence). 4. Expand the SVGPathSink functionality in 2Geom, so that feeding paths to Cairo is done using this nice interface.
Regards, Krzysztof