[librsvg.wiki] Continue the roadmap



commit e7f8fbef412bad7ec8fb1ec8176a244c619e50fe
Author: Federico Mena Quintero <federico gnome org>
Date:   Fri May 7 22:12:34 2021 -0500

    Continue the roadmap

 roadmap-2021-05.md | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)
---
diff --git a/roadmap-2021-05.md b/roadmap-2021-05.md
index c68eb6a..bf4319a 100644
--- a/roadmap-2021-05.md
+++ b/roadmap-2021-05.md
@@ -34,7 +34,7 @@ public error
 types](https://gitlab.gnome.org/GNOME/librsvg/-/issues/657).  For
 example, `LoadingError::XmlParseError(String)` is just a
 human-readable version of `xmlError` from libxml2.  If librsvg changes
-its XML parser to a Rust one, we should be able to provide more
+its XML parser to a Rust one, it should be able to provide more
 detailed errors via `Box<dyn Error>` opaque variants.
 
 Issues: [#635](https://gitlab.gnome.org/GNOME/librsvg/-/issues/635),
@@ -43,3 +43,61 @@ Issues: [#635](https://gitlab.gnome.org/GNOME/librsvg/-/issues/635),
 ## Medium term goals
 
 ### Make it possible to move away from Cairo
+
+**Why?** Cairo's maintenance record is very spotty, and librsvg is
+being hit by bugs or limitations in Cairo that don't seem likely to be
+fixed soon.  Also, the move to centralizing Cairo calls (instead of
+spreading it all over the code) has made the rest of the code much
+cleaner.
+
+Note that there is no decision yet on what to use.  Skia?  Tiny-skia
+(a minimal Rust port)?  Raqote?  Custom paintables for GTK4 that can
+render paths in the GPU via Pathfinder?  Or a selection of them:
+librsvg definitely needs a CPU renderer to spit PNGs; GTK and probably
+other toolkits would probably like GPU rendering at some point.
+
+It would be "easy" (note the air quotes) to add support for other
+rendering backends if librsvg produced a display list for the SVG
+document, and then just rendered *that* display list, instead of
+trying to do everything in a single traversal of the tree and
+maintaining a giant ball of mutable state.
+
+#### Current architecture / code flow
+
+Librsvg's current code still inherits the code flow that it had in the
+C days: it builds a DOM tree, and then renders the SVG document in a
+single traversal of the tree.
+
+**Data representation:* each `Node` serves both as a DOM node and a place
+to hold the parsed data specific to each SVG element.  For example, a
+`Node` for a `<rect>` contains the XML attributes, the
+`SpecifiedValues` and `ComputedValues` for the element, and an
+`Element::Rect(Box<ElementInner<Rect>>)` with the parsed values of the
+`x/y/width/height` attributes.  This is not wasteful, but it is
+unwieldy and mixes several responsibilities into the `Node`.
+
+*Rendering in a single traversal of the tree:* initially the rendering
+information was a giant ball of mutable state in `DrawingCtx`, but we
+have been splitting that into multiple things that are now passed as
+arguments to the rendering functions:
+
+* `DrawingCtx`: Maintains a stack of viewports or coordinate systems,
+  and stack of surfaces to be composited.  Also holds the Cairo
+  context, which is itself a little microcosm of mutable state.
+
+* `AcquiredNodes`: This is a cycle detector to prevent infinite
+  recursion among referenced nodes.  It is unfortunate that this gets
+  passed around everywhere, because patterns/gradients/filters/masks can
+  reference other elements in the DOM and they are resolved until
+  close to the last possible moment.
+  
+* `CascadedValues`: Although librsvg runs the CSS cascade by
+  traversing the tree once before rendering, it still needs to handle
+  cases like the `<use>` element: the node it references does not
+  cascade from its parent, but from the `<use>` element instead.
+  Librsvg does not implement a Shadow DOM; instead, to render a
+  `<use>` librsvg actually traverses the referenced node but with a
+  different cascading mode than the usual.  The `CascadedValues`
+  argument tells that sub-traversal, "don't cascade from your parent;
+  use this other set of `ComputedValues` instead".
+  


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]