KDE To Adopt SVG: Take A Glance

Karma Sucks writes "According to the KSVG website, KDE 3.2 will be adopting SVG in a very real way. A special preview of KSVG is available, showing everything from font rendering to a snowfall simulation using ECMAScript and DOM. KSVG is fully integrated into the KDE framework and can be used as a KPart -- e.g., by applications such as Atlantik."

Comments

Scalable Vector Graphics.

[Adolph_Hitler]

SVG is a new way to render without pixels, it requires less ram but more of a CPU hit, since our CPUs arent actually being used its a fair trade off for resolution indepedance, speed, and special effects. It could allow Linux to compete with or even surpass OSX and Longhorn.

Re:Scalable Vector Graphics.

[Selanit]

SVG is a new way to render without pixels . . .

Um, no. SVG does use pixels. If you come up with a way to display something on a screen without using pixels -- get a patent!

What you were trying to say, I think, is that SVG generates vector graphics as opposed to bitmapped graphics. Bitmapped graphics are basically lists of pixels, saying "First row: pixel 1 is red, pixel 2 is red, pixel 3 is green. Second row: pixel 1 is red, pixel 2 is green, pixel 3 is red. Third row: pixel 1 is green, pixel 2 is red, pixel 3 is red." This generates a three-by-three graphic like this:

RRG
RGR
GRR

In other words, a red square with a green slash extending diagonally upwards from the bottom left to the top right. You can save some disk space by compressing the file -- for example, the file might say "Green pixels: Row 1, pixel 3; Row 2, pixel 2; Row 3, pixel 1; all others Red." Other compression schemes use different approaches, but that's one way. At base, though, it's still just a list of pixels. Examples of bitmapped graphics include BMP, JPG, PNG, and GIF graphics.

Vector graphics are different. They specify a set of mathematical descriptions of shapes. Like plotting out the algebraic formulas for lines and squares and stuff on a graph in high school. Instead of describing the picture, vector graphics describe how to draw the picture. The advantage to this is that the picture can be drawn at any size. You could take a vector graphic and draw it at 3x3 pixels or 3000x3000 pixels, and the end result would be true to its description. You can enlarge something indefinitely without it getting all pixellated and blocky. You can also reduce it indefinitely. Of course, at one point or another it gets too big or too small to be useful, but in between those points it gives you a lot of flexibility. Sick of those miniscule icons in the toolbar of your word processor? If they were SVG, you could twiddle their size until they felt comfortable. Some of the better-known examples of vector graphics are TrueType fonts and Macromedia's Flash graphics.

SVG, which is short for Scalable Vector Graphics, is an open, XML-based standard for vector graphics, similar to Flash. You use XML tags (vaguely like HTML) to describe your shapes and such. Then you need an interpreter that takes those instructions, figures out the math, and draws the shapes for you. You can animate them with ECMAscript (read: JavaScript). The standard is fairly new, but has a lot of backing.

In KDE, icons are the most obvious use for SVG. There is a definite performance hit -- all that math means a lot of CPU overhead. For this reason, I don't think SVG is likely to be used to generate the whole interface. But there's an excellent compromise: once the SVG has been sized and drawn, you could then take that and save it as a bitmapped graphic. So you could size your interface once, then save to plain old bitmapped files, using compression if you like. That way you get your UI sized the way you want it, and you don't have to keep re-calculating all the vectors.

It's a spiffy new technology, and has a lot of potential applications. Neaaat.

Re:Scalable Vector Graphics.

[be-fan]

Vector graphics are almost always rendered via the CPU (even Quartz "Extreme"). There is an OpenGL accelerated renderers for SVG (SVGL), and a few custom 2D APIs on top of OpenGL (like EVAS). However, there isn't really anything production quality yet.

A (tm) Damn Good Thing.

[Bowie J. Poag]

SVG, whether you like it or not, may very well be the future as far as graphics...at least as far as GUIs are concerned.

Scalability has become increasingly more and more important on the desktop in recent years, and it's nice to see KDE recognize that.. Beyond the savings associated with going vector over raster, it's just a better idea. A better tool for the job. Sure, it's not going to replace traditional rasterized images (i'd imagine it's pretty hard to distill a rasterized image into a decent vector) but it's a step in the right direction. The right tool for the right job.

Cheers,

Holy Freaking Slashdotting batman! (Unixcode.org)

[LordKazan]

Just talked to Capzilla over from Unixcode.org - he's getting flooded with requests right now so be patient with his server. Sometimes /. readers are like a pack of wolves to descending on a poor defenseless webserver.

Re:Wicked cool!

[be-fan]

Too bad you have no idea what you're talking about. OS X is hardly competiton for KDE.

a) SVG has nothing to do with text quality --- current fonts are scalable, but they are rendered by highly optimzed renderers like Freetype to apply font-specific hinting.

b) OS X doesn't use vectors. Most things (widgets, etc) are still bitmaps. The graphics system supports vector graphics (and some apps like Quicktime use them) but most of the eye-candy in OS X is just the result of good UI designers. Hell, it doesn't even use scalable icons --- it starts with large (128x128) bitmaps and uses pixel scaling.

c) OS X doesn't render vectors via hardware. If you look at the tech docs, Quartz 2D is all CPU. OpenGL is merely used for transparency and window-level effects like genie.

d) An all-SVG UI wouldn't necessarily be bad, it would just not be terribly useful. First, UIs are already pretty scalable. For example, I was looking through the code for the Plastik KDE theme the other day. Most of the drawing logic is completely scalable. I was able to rip out of a lot of the hard constants and make them read via a configuration file. You change a few constants, and suddenly scollbars and spinners are wider, *and* properly rendered. All the buttons and tabs are aleady scalable, because Qt is a font-sensitive UI, and changing font-sizes can drastically affect the size of widgets.

However, you still have to care about pixels. Resolutions are still not high enough where you can ignore them. Plastik (and other themes, presumably) still has special cases to handle small pixel shifts (think of a limited case of hinting). Even on my high res screen (133 dpi) a small shift of one pixel on a scrollbar is easily visible as a glitch.

Re:Answer to Apple's Quartz

[be-fan]

SIgh. Apple's UI apparently scales terribly. Its supposedly the reason why Apple is still shipping low-res laptop screens in this age of 1920x1200 15.2" LCDs. If you look closely, OS X is really full of bitmaps. Hell, its got more bitmaps than most KDE or GNOME UIs. The scrollbars in most KDE themes, for example, are rendered on the fly via Qt's Painter API, while in OS X, they are bitmaps.

Re:screenshots

[westyvw]

Beacause in KDE you can do that. Of course.
You can set up little "docks" in any side of the screen. KDE is my favorite desktop (on a fast computer) on slower I like a mix of fluxbox and enlightenment.

Re:Why XML?? Just why?

[Anonymous Coward]

Because your describing the geometry of an object using SVG. A JPEG, doesnt describe functions that render the object, it's just a table listing all the attributes of the image. In SVG the file is a mathematical description of the object. It lists all the methods in addition to a few attributes that together describe the object.

Re:Why XML?? Just why?

[Anonymous Coward]

I forgot to write what this has to do with XML.
Since you are dealing with mathematical formulas and much less data, its much easier to take on object and actually change, partition and relate parts of it the whole in different ways, in other words SVG images can be treated like documents.

Re:Somehow, this came to mind ...

[jazzmans]

Goood Morning VietNam!