I am struggling a bit with the overall structure of Inkscape's code as I
work on getting filter regions implemented correctly. This is how I
understand the current structure to work:


XML Tree:

    This represents the actual document.

SP Tree:

   This is an expanded tree. For example:

     <defs>
       <rect id="myRect"/>
     </defs>
     <use xlink:href="#myRect"/>

   has two SPRect instances, one for the <rect> in the <defs> section
and one generated by the <use> element. The allows for things such as
style cascading and for different dimensions when the rectangles size is
expressed in percent of the viewport (and there are multiple viewports
in one document).

   Markers and symbols may also have multiple instances generated.

   The SP tree includes print functions used by the EMF, WMF, and TeX
exporters. Other exporters (including Cairo PDF and PS) are independent
of the SP and NR trees.


NR Tree (e.g. Cairo Renderer):

   This is an expanded tree created for on-screen rendering.

   (Silly questions: what does NR mean?, what does 'arena' mean?)


Now we come to filters. A filter can be applied to multiple objects.
It's coordinates can be expressed in terms of the current viewport or
the bounding box of the object that references it. In both cases, a
filter's absolute coordinates can be different when applied to different
objects. At the moment, only the bounding box case is handled and it is
handled in the NR Tree. The NR tree doesn't know about the viewport but
the SP tree does so I've tried to add code to handle the coordinates
expressed in terms of a viewport into the SP tree. It seems more natural
to handle coordinates in the SP tree as the SP print functions and other
exporters can take advantage of these dimensional calculations. This
works, kind of. There are a couple of problems:

    1. The update functions of the filter primitives are not called.
This can be fixed by adding explicit calls from SPFilter::update
(following the model in the SPGroup update function).

    2. The filter update function is only called once, at the beginning
of the update process. So if a document has more than one viewport (due
to an embedded SVG, for example), the filter coordinates are not updated
for the second viewport. (This is unlike the <use> element case.)

It seems my choices for fixing filter regions for viewport based
dimensions is to either follow the <use> element example, and have
instances of the filter element for each use of the element or to move
all coordinate handling to the NR tree (after making the viewport
available in the NR tree). The former, I think, is more desirable, but
the latter may be easier.

Any thoughts?

Thanks,

Tav




------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel