RiverSoftAVG Products Help

•Use TSVGDocument to draw an SVG to a canvas This is the most flexible way to use the RSCL and one of the fastest.  You can draw your SVG to any canvas, including printer canvases.  By using the TSVGDocument.DrawBeforeElement/DrawElement/DrawAfterElement methods, you can achieve the highest redraw rates while editing elements (see the SVGEditorFMX demonstration for more details).

•Use TRSSVGImage to display SVGs The TRSSVGImage displays a graphical image of an SVG. The control ensures that the image is always of the highest resolution by redrawing the SVG when the control is rescaled.  By setting the Buffered property to true, the TRSSVGImage control will draw the SVG to a backbuffer and then copy that image to the canvas (default) or to draw directly on the canvas for extremely fast updates of the SVG (after the initial draw to the backbuffer).  Set the Buffered property to false to draw directly on the image canvas. This is generally not recommended, however, it may look better on mobile devices.

•Use TRSSVGPanel to display SVGs The TRSSVGPanel Component provides a panel for generating design-time or run-time controls (e.g., TLayout, TText, TRectangle, etc) for a SVG. Unlike the TRSSVGImage component, the TRSSVGPanel component does not draw the SVG using canvas operations. Rather, it generates the FMX controls to draw the SVG.  

The TRSSVGPanel control is the least compatible way to display SVGs.  In addition, it consumes the most memory and is the slowest to generate your first SVG display (However, it can be very fast to display subsequently as it just uses Delphi controls for drawing).  The advantage of the TRSSVGPanel is that you do not need to deploy an SVG with your application, and you can edit every SVG element's control using the object inspector.  You can also add effects in FMX.

Note that the VCL panel version is the slowest, least flexible, and least compatible way to display SVGs in the RSCL.

•Use TRSSVGImageList to manage multiple SVGs

•Load an SVG into a TBitmap (FMX) or TGraphic (VCL)

As much as possible, the RSCL tries to achieve functional parity between the VCL and FMX versions.  However, the limitations of the different Delphi libraries do force some differences.

•VCL has clipping for irregular shapes (which can speed up rendering)

•VCL can fill text with gradients or pattern when using Fill Text option

•VCL supports TextRendering/ShapeRendering/etc properties

•VCL TRSSVGPanel is much more limited than FMX version

•FMX radial gradients are slightly better visually (with patch, see XE8+ Notes)

•FMX rendering is generally faster

The RSCL provides two methods for rendering text: path-based text and fill text. The default method is path-based text on desktop platforms.  In path-based text, the text is converted to paths, cached, and then drawn using the paths.  It has the advantage that text can be both filled and stroked, and allows pixel level precision for selection.  The path-based text method is slower than fill text for the initial draw call; however, the RSCL caches shapes and so path-based text can be faster for complex text after the initial draw.  With fill text, the text is drawn directly to the canvas using fill text calls.  It is faster initially and uses much less memory.

The text rendering method is controlled by the soUseFillText in TSVGDocument.Options property. On mobile platforms (iOS and Android), or if you use the FMX GPU Canvas (FMX.Types.GlobalUseGPUCanvas), text is always filled and not converted to paths. The TSVGCustomText.IsFillingText method returns true if the RSCL is using the fill text code.

The following differences exist between the two text rendering paths:

•Fill Text does not use the Pen and so cannot both fill and stroke text

•Fill Text cannot use gradients for filling (FMX)

•Fill Text uses less memory

•Fill Text generates better text at small sizes

•Fill Text does not do center and right alignment for complex text (i.e., text that has dx, dy, rotate, vertical writing mode, etc style properties defined)

•Fill Text has better compatibility with non-Western fonts

•Path-based text can both fill and stroke text (however, on non-Windows platforms gradients are not used in stroking text)

•Path-based text caches its shapes so subsequent draw calls are faster, even faster than fill text calls in many cases

•Path-based text allows pixel level selection of text; Fill Text can only be selected as a text bounding box

•Path-based text renders decorative fonts (underline, overline, and strike-out) using an extra path for the decoration (FMX will not generate paths with the decoration when converting text to paths). Surprisingly, this means that compatibility is higher with path-based text as the decoration gets its rendering configuration from the parent text element (e.g., strike-out text should use the parent text's font size and not vary as the size of child text span's font size changes).

•ShapeRendering affects the smoothness of text when filling path-based text (as text are shapes); TextRendering affects the smoothness of text when filling text