KDE [KDE] is an international technology team that creates Free Software for desktop and portable computing. Among KDE's products are a modern desktop system for Linux and UNIX platforms, comprehensive office productivity and groupware suites and hundreds of software titles in many categories including Internet and web applications, multimedia, entertainment, educational, graphics and software development.
KDE 4 is the latest release of the KDE software stack. One of the most notable changes in KDE 4 is a pervasive usage of SVG. SVG files are used for themes, icons, storage system and transport. They are at the beating heart of beauty of the KDE 4 interfaces.
Furthermore, the whole graphics stack utilized by KDE has been heavily influenced by the SVG standard. A new Free Software graphics driver model, called Gallium3D, has been written in order to utilize modern graphics hardware for accelerating API's such as OpenVG and OpenGL to assure real time rendering of SVG files using minimum amount of resources. On top of that the Qt library, which KDE is layered upon, has a graphics API fully compatible with the SVG rendering model.
To cope with variety of uses of the SVG technology KDE comes with two SVG rendering engines. Th SVG 1.2 Tiny [SVG12] compliant QtSvg library, which is meant to be a minimal rendering engine, suitable for things like icons, and QtWebKit's SVG which is a full SVG engine.
KDE 4 has just begun its existence and almost every day engineers working on it come up with new and creative ideas, tools and use cases for how to better utilize SVG. Unlike most of the technologies leveraging SVG, KDE's focus is on interactivity and animation. A whole set of tools and utilities has been developed to aid that goal. The best example of such uncommon usage of the SVG standard is the Plasma [Plasma] project, which comes with its own animation framework layered on top of the SVG rendering model.
The openness of the SVG standard aided by the creativity of the Free Software engineers created something truly unique and exceptional.
Table of Contents
Definition of KDE [KDE] is intentionally broad. KDE started as a software project, the name itself stood for the "K Desktop Environment" and clearly described the purpose of the project. KDE now provides an easy to use contemporary desktop environment available for UNIX and compatible systems. Together with a free implementation of UNIX such as GNU/Linux, UNIX/KDE constitutes a completely free and open computing platform available to anyone free of charge. Source code is available for anyone to look at, learn from, modify and improve. Whilst there is always room for improvement, KDE today delivers a viable feature packed alternative to the more commonly found commercial operating systems/desktops combinations available.
What makes KDE very unique is the community around it. A group of people connected by the ideals of freedom, beauty and usability make KDE a living entity. As all living beings KDE evolves. From its humble start as a desktop environment it became an ideal, of Free Software and creative freedom, that binds engineers, artists, translators and all its users.
Besides a desktop environment KDE produces a whole suite of libraries, frameworks, applications and art. At the graphical core of it all stands SVG.
The first version of KHTML was officially released as part of the KDE 2.0 release on October 23rd, 2000.
Soon after the release of KHTML Rob Buis and Nikolas Zimmermann started working on KSVG1. KSVG1 was essentially a fork of KHTML adjusted to support SVG. The forking was necessary because KHTML had no public interfaces that would allow hooking in the DOM external rendering API's. Due to those shortcomings Rob and Nikolas decided to create a DOM library which could be shared by both KHTML and KSVG libraries. The resulting solution, called KDOM, was the reason why KSVG2 was born.
Around the same time developers at Trolltech were working on the first release of the version 4.0 of the Qt toolkit [Qt]. Qt is a cross-platform application development framework, widely used for the development of GUI programs, and also used for developing non-GUI programs such as console tools and servers. Qt is the foundation of the KDE software. One of the main features of the new release of Qt was a completely rewritten graphics engine called Arthur. The rendering model in Arthur has been heavily influenced by the SVG 1.1 standard and made to be compatible with it. Some of its new features included fill brushes, alpha-blended drawing, anti-aliasing, using paths as a graphical primitive and stroke and fill transformations.
As part of the internal framework to test Arthur a small application, which was rendering SVG files, has been created. The combination of Qt graphics and SVG captured the minds of engineers at Trolltech and the QtSVG library was born.
An implementation of SVG with full DOM and Ecmascript support, created largely by the KSVG developers, has been added to the WebKit project. WebKit was originally derived from the KDE's KHTML library by Apple, Inc. for use as the engine of Mac OS X’s Safari web browser, and has now been further developed by Apple, Nokia, Google and others. Qt 4.4 marked the first official release of the QtWebKit library.
With QtSVG and QtWebKit KDE has two excellent SVG rendering engines.
As previously mentioned the rendering model used by the current major version of the Qt toolkit has been hugely influenced by the SVG standard. Resolution independent UI has been a very tempting proposition for the Qt developers and it was very clear that it could never be achieved without a great graphics framework.
Due to the cross platform nature of the Qt toolkit the rendering engine had to be capable of rendering on multiple platforms, to a lot of various surfaces using a number of different native API's. A side-effect of this design is that the users of the API are capable of selecting which backend will be used for rendering (a number of different accelerated API's is supported including OpenGL, OpenVG, Direct3D and Xrender). At the very core of the API sits a QPainter object which is responsible for propagating the actual drawing commands to platform specific QPaintEngine which in turn renders to an object derived from a QPaintDevice. QPaintEngine abstracts the rendering backend, e.g. OpenGL, Xrender, Direct3D. QPaintDevice can be thought as the surface to which the given backend is rendering to e.g. in the case of the OpenGL QPaintEngine those could be pixel buffers, framebuffer objects or simply GL windows.
The principal graphical primitive of vector graphics is a path. In Qt they are described in a QPainterPath object. Abstraction of the rendering model in the form of QPaintEngine allows utilization of different methods of rendering paths. The raster engine (one which renders on the CPU to a memory buffer) uses scanline rasterization [Turner07], the X11 engine uses tessellation and OpenGL engine uses the stencil method.[RedBook]
The QPainterPath abstracts some useful operations on paths like simplification (removal of self-intersections), boolean operations (e.g. union of paths) and positioning of objects on the path itself. This allows applications using Qt to create very attractive vector graphics effects with ease.
One of the examples is dynamic generation of shadows:
A commonly used effect is positioning of objects on the path and animating them:
Another is layouting of text on a path:
On top of the typical vector graphics features Qt adds a few additional elements to its rendering model.
Perspective transformations allow creation of 3D like effects in a 2D environment. While 3D user interfaces tend to be a usability nightmare, 3D effects in 2D interfaces are becoming more and more popular. A whole set of those effects can be achieved by simple projective transformation. This functionality is often referred to as 2.5D effects. Ability to achieve flipping of elements along X or Y axis are the reason why, instead of a simple affine matrix, Qt uses projective matrix and does its graphical operations in homogeneous coordinate system.
A famous example of perspective transformations in a 2D interface is the famous album cover widget:
Visually KDE 4 desktop has been largely built on top of SVG. Most of the user interface elements of the desktop have been styled with SVG files.
The Oxygen icon theme was started by David Vignoni, Ken Wimer and Torsten Rahn during the first Appeal Project meeting held in Berlin on March 2005. All the icons are SVG vector images, adhering to a well defined color palette and feel.
When one of the KDE applications asks for an icon, the icon loader checks the cache for already existing icon at the specified size. If the cache contains the icon at that size, the image is returned if not, respective SVG file is loaded, the icon is rendered, inserted into the cache and returned. This allows KDE applications to share the same icon theme and use resolution independent icons while avoiding most of the overhead associated with constant re-rendering of the SVG files.
Plasma [Plasma] is one of the key technologies of KDE 4, and one of the most visible to users. It is the component that is "in charge" of the desktop interface; the desktop, panel and related elements. Plasma has been designed in a way that makes it possible to easily and conveniently change its visual characteristics. Plasma can use "themes", which are essentially a number of SVG images and files specifying the colors and shapes, to change its appearance. This means there is no need for theme authors to know C++ or any other programming language to create a great looking theme.
The center of Plasma's styling infrastructure is occupied by the Plasma::Theme object. Plasma::Theme abstracts the look of the KDE desktop - from colors, through dialogs, wallpapers to widgets. The interface for rendering SVG is held within the Plasma::Svg object. Besides abstracting SVG specific functionality Plasma::Svg class has knowledge of the currently selected theme, this in turn allows it to automatically change every single element of the desktop once a new theme has been selected.
A division of the KDE project is dedicated to computer gaming and entertainment software. KDEGames, as it is called, is the community dedicated first and foremost to the creation of only the most enjoyable and amusing playware. To date KDEGames has accumulated an impressive selection of quality games in nearly all genres.
KDE 4 release marked the first release of the KDEGames based on the SVG standard. Nearly 20 games have been almost rewritten from scratch to make use of vector graphics. The games use the SVG files not only the theme individual elements but to structure the whole layout of the game.
Extensive usage of animations was possible thanks to encoding individual frames with specific ID's. So while the SVG files contain a static data, the code itself can easily create animations by interpolating between shapes by referencing them via their ID's. The size of the SVG files, which are used for animations, has been reduced thanks to the usage of the "use" element, which links to the already defined primitives. Such extensive usage of SVG art allows artists to participate in the project without touching a single line of code. The developers are able to create the logic and the engine behind the game and then have artists style it to their liking.
Currently the KDEGames project contains the largest selection of SVG utilizing games in the world.
Due to KDE's bleeding edge usage of SVG we were forced to deal with a few new problems. While resolving them internally helped us push the desktop metaphor further, we feel that a few of those problems need to be addressed on a more global scale. In this section we will present the most visible problems we have encountered and propose some sample solutions.
One of the major problems that Qt/KDE applications are facing is a dreaded "rounded corner" problem.
In modern interfaces there's a strong desire to make the transition between elements seem smoother. That implies heavy usage of gradients and rounded, instead of sharp edges. The human brain has been conditioned to see sharp transitions and rough edges as a warning sign. In turn that makes them visually displeasing. Huge effort has been put into the KDE 4 interface to make sure that all the transitions are as smooth, peaceful and visually pleasing as possible. That is why KDE 4 user interfaces make a heavy usage of rounded corners.
Due to styling the visual appearence of the elements is often encoded in the SVG files. Unfortunately in SVG 1.2 Tiny standard the path element doesn't contain the arc elements and the rounded corner arcs are created with Bezier curves. Unfortunately not uniform scaling in either direction changes the curvature of Bezier curves, a side-effect of which is a complete change in the appearance of the element.
To solve that problem elements with rounded corners are split into multiple segments. Each segment get a different XML:ID and the the code renders each segment individually. This allows the application to control which segments get scaled, e.g. rounded corner never get scaled but straight horizontal and vertical segments are.
A proper SVG solution would involve addition of another path segment type, e.g. ARC, with a well defined scaling behavior. A different solution could involve adding extra properties to paths e.g. path element #3 can only be uniformly scaled. The former being an all around simpler solution. The advantage of the latter one is that it could be used for animations to ease the problem of path interpolation.
The loss of quality in vector graphics at small size is a severe problems. Rendering vector graphics primitives at low resolutions introduces a certain amount of blur into the output. This is mainly caused by horizontal and vertical primitives which happen to fall between pixel boundaries, which in turn makes the anti-aliasing algorithms try to cope with it by rasterizing two, instead of one rows/columns but at a lower color intensity. For primitives which are rendered at small sizes the goals of "resolution independence" and "preserving their good looks across resolutions" diverges a lot. We have the former, we need the latter.
One of the ways of dealing with this problem is hinting. The problem of hinting vector graphics primitives has been extensively researched by the way of font technologies. Grid-fitting (aka. "font hinting") is a crucial step on the way to produce legible output at small sizes for a lot of fonts. Hinting can be manual (e.g TrueType has a stack-based language for it, each glyph in the font contains its own little hint program and as a result of running that program control points for the outlines can be adjusted in any way the creator of the hints desired) or automatic (as used by FreeType). An interesting medium is described in "Example-Based Hinting of TrueType Fonts" paper, in which a method of reusing hints from one font for another are described. All in all it's a very common problem for fonts.
The research the engineers from the FreeType project conducted on auto-hinting is outstanding. Right now the way KDE artists go around this problem is by producing certain SVG icons with different viewport sizes. This allows them to manually adjust the rendering for certain native resolutions.
The reality of the situation is that without very high DPI displays the quality of small SVG renderings is going to suffer. A solution would involve introduction of either an auto-hinting algorithm or adding a declarative approach of specifying the hints which the artists could easily utilize. It's a problem which affects all SVG users and should be handled in the standard itself.
Lack of authoring tools supporting creation of SVG animations forces developers to utilize various hacks to create dynamic interfaces. While QtSvg library supports procedural animations, as defined in SVG 1.2 Tiny Standard, they are virtually never used in practice. They are far too limiting to express complex user interface interactions with them. SVG is canvas based, which makes it significantly different from other formats which can be used for animations, as they are frame-based. One of the major features missing from SVG is the ability to interpolate paths. Defining a starting, ending shape and letting the technology do the work to interpolate between them and automatically create an animation has been very popular lately.
The lack of tools that could be used to create animations is the core problem. Furthermore the requirement to use full DOM scripting in order to incorporate simple interactivity within the created interface makes the process of creating even the simplest animation quite complex. Currently KDE works around that problem, by making SVG a completely static format. The animations are defined in code which loads SVG, selects the elements from the SVG (via xml:id) and manipulates them independently of the SVG they were loaded from.
The solution has to be a combination of work put into the tools and the standard. Artists have to be able to use the authoring tools to quickly prototype animations. The format needs to make it simpler for developers to interact with animations. An additional element which would automatically interpolate between starting and ending paths would be very helpful. Furthermore an simplistic scripting model, much like the one used by JavaFX would be highly desirable. Another technology worth looking at is QEdje [QEdje] which provides a simplistic abstraction layer between the application code and interface.
In order to create realistically looking graphics a fair amount of shading techniques has to be used. In vector graphics shading effects are achieved with gradients. Unfortunately the gradient primitives specified in the SVG standard are very limiting. Artists have a hard time working with both linear and radial gradients.
To solve the shading problem a concept of "gradient meshes" has been introduced. A gradient mesh is a lattice which stores color information at each vertex. During rendering the colors stored at the vertices are linearly interpolated. Gradient meshes are a lot more powerful tool than linear or radial gradient. Unfortunately the toplogical complexity of them is often prohibitive for real-time vector graphics. Furthermore creating more complex gradient meshes is a very slow process requiring a lot of work from the artist. Recently some reserach has been done on the topic of auto-vectorization using optimized gradient meshes by Sun et al [Sun07] but while their approach simplifies the topologies it doesn't help free-hand creation of art at all.
A realization that most color variations in an image can be assumed to be caused by edges led to creation of a new vector primitive called a "diffusion curve" [DiffCurves08]. To quote the paper "A diffusion curve is a curve that diffuses colors on both sides of the space that it divides". This simple representation is capable of representing even very subtle shading effects. The concept is based on a number of research papers which proved that edges constitute a near-complete and natural primitive for encoding and editing images. It's also a model that closely matches the creation of SVG art as the primitives are naturally used to encode the edges. It's also the reason why the gradient model in SVG is disconnected from the process of creation of the actual shapes. The primitives themselves can be rather complex curves but shading between those curves can only be either be rectangular (for linear gradients) or circular (for radial gradients). Diffusion curves remedy that fact by seemingly integrating shading into the process of art creation instead of making it an afterthought.
A simple example of a rendering created with diffusion curves is shown below along a image showing diffusion curves used to create it.
Introduction of either gradient meshes or diffusion curves would fix the problem. While gradient meshes are a lot less natural fit for SVG, due to the inherent complexity in manipulating them, diffusion curves make them an almost perfect fit for SVG. Furthermore with diffusion curves the shading model can be incorporated right into the path element.
[Turner07] How FreeType's rasterizer work. http://cvs.savannah.gnu.org/viewvc/freetype/freetype2/docs/raster.txt?view=markup. Copyright © 2007 David Turner.
[Sun07] Image vectorization using optimized gradient meshes. Copyright © 2007. 3. ACM. New York, NY, USA.