[librsvg/librsvg-2.40] rsvg-cairo-draw: Comment on how we should be computing bounding boxes for viewports/clipping

[Federico Mena Quintero <federico src gnome org>]

commit d8c442fe03e9bec67abd0fd59836ccf051230e16
Author: Federico Mena Quintero <federico gnome org>
Date:   Fri Sep 1 07:12:13 2017 -0500

    rsvg-cairo-draw: Comment on how we should be computing bounding boxes for viewports/clipping

 rsvg-cairo-draw.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
---
diff --git a/rsvg-cairo-draw.c b/rsvg-cairo-draw.c
index 6ae8e07..9e098fa 100644
--- a/rsvg-cairo-draw.c
+++ b/rsvg-cairo-draw.c
@@ -490,6 +490,19 @@ rsvg_cairo_render_path (RsvgDrawingCtx * ctx, const cairo_path_t *path)
        _rendering_ time speedups, are these rather expensive operations
        really needed here? */
 
+    /* FIXME: See https://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox for
+     * discussion on how to compute bounding boxes to be used for viewports and
+     * clipping.  It looks like we should be using cairo_path_extents() for
+     * that, not cairo_fill_extents().
+     *
+     * We may need to maintain *two* sets of bounding boxes - one for
+     * viewports/clipping, and one for user applications like a
+     * rsvg_compute_ink_rect() function in the future.
+     *
+     * See https://bugzilla.gnome.org/show_bug.cgi?id=760112 for discussion of a
+     * public API to get the ink rectangle.
+     */
+
     /* Bounding box for fill
      *
      * Unlike the case for stroke, for fills we always compute the bounding box.