SVG support in CEGUI

The purpose of this document is to determine how the SVG loading/handling and storage of related datastructures should be done.

Specific questions that need to be decided upon are (in the brackets the current state of decision will be noted, if existing):

Module-integration:

• SVGImage and related files will be a part of CEGUI Core-library (yes)
• Vector graphics rendering related files will be part of CEGUI Core-library (yes)
• The SVG File loading and parsing will be part of CEGUI Core-library (undecided)

Structure:

• SVGImage will be a subclass of CEGUI::Image (yes)
• SVGImage contains the cached information required for rendering (yes)
• A class called VGShapeData, VectorShapeData, VectorData or similar, will contain the abstract information on the shapes which is used in SVGImage to be cached and drawn (undecided)
• SVGImage will contain a reference to a shape-data class. This means that multiple SVGImages can share the same shape data. The question is if this is necessary (use-case?). If this data was shared and the user modified this data, all VGImages would have to be updated. An alternative would be that the shape-data class can only be referenced once, but can be copied and then altered if required. (undecided)
• CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (undecided)

Notes: Probably SVGImage should rather be called VGImage or VectorImage or VectorGraphicsImage. This is because it should be easily possible to make that the class would not require actual SVG data but instead only require shape information for drawing. The SVG data can be converted into such abstract shape information. That way users can create their own shape information and which can be used in a VGImage. None of the names should refer to "SVG" as a name in my opinion, except for the SVG parser itself. Everything after the parser should be "general" although the whole data structures and drawing process will be designed in the first line to go well along with the SVG file standard and its definition of vector graphics.

We should probably think of a general naming concept

Possible use-cases for SVG Images

As justification for the above suggestions following use-cases can be considered:

• A user wants to load an SVG-file and then use the resulting SVGImage like a regular raster graphics image (BasicImage)

For this purpose, in the optimal case, the user could use an SVGImage equally to a BasicImage. Which means, it can be referred to via a String, defining the name of the Image. The VGImage would therefore have to be registered and maintained by the ImageManager in the same way as raster graphics. Autoscale and scaling in general, as well as any clipping have to be handled appropriately for that case. Stretching and alignment also have to be considered.

• A user wants to create a drawable Vector graphics image, e.g. a mouse cursor, by defining it manually using CEGUI classes

The class maintaining the shape information has to store the draw-information the user wants to generate. An instance of this class has to be created using a CEGUI Manager. When it is constructed it should be possible to call functions that write the draw commands to this file. Such a command could be for example: addDrawLine(Point start, Point end, thickness, Colour col, ...) The question is if this function should remain inside the class storing the data, or if a Helper or super-class should deal with the interpretation of the draw command. Probably it is better to seperate it in some way from the data storage class (VectoData) to prevent it from containing too many function that are not of direct relevance. Alternatively, each draw shape could be a seperate class. This might be the best solution as the data structure would only need an add(const Shape& shape) function and therefore the rest would be duty of the specific implementation of the Shape. The Shapes would be passed as copy to the the data storage class so that the user doesnt have to take care of its memory management later-on. The data storage class would be managed by a Manager, similar to CEGUI::Texture and therefore could be addressed via a String and would be deleted and created analogously.

• (Optional/for post-GsoC) Usage of Animated Vector Graphics

Subclass of SVGImage, containing a time variable as addition. Needs to be updated on each update call that includes a time-change. This also requires recaching. Currently I do not see further issues with that, the main problem with these is the recaching process itself.

Currently I cannot think of further use-cases.