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

Thats not good enough! We need an SVG interface!

[Adolph_Hitler]

The KDE team needs to do more than just adapt SVG as a plugin, they need to render the whole interface via SVG. Maybe cairographics could be used as the backend, and KDE's UI, Icons, Widgets etc could be completely resolution indepedent and rendered via SVG.

Whoohoo!

[Exiler]

Now we can finally play Asteroids in all its full glory ;)

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.

Wicked cool!

[GrouchoMarx]

This is extremely cool for many reasons.

1) It means that KSVG, which was stalled for a long time, is now stable enough to be considered part of the base system. That is good news for SVG adoption in general, as it means that Konqueror 3.2 will likely have native SVG-with-animation support. Finally, an out-of-the-box fully-SVG-enabled browser other than IE-with-Adobe. :-) It's also quite likely that once the KHTML integration is complete, it will end up in Safari as well, which is good for everyone.

2) SVG should not be used for the entire UI, that's overkill, but for many areas it makes life a lot easier. For instance, icons in SVG make them infinitely scalable, so that people can resize their screens or their icons to whatever they find comfortable with no loss of quality. (Think handicapped.) Also, no more need for Small and Large versions of icons. Just have one icon, and the system scales it to whatever size is needed.

3) Hopefully, this will mean better support for SVG creation. KDE's SVG editing tools are still not the best. What I really want is to be able to use SVG as an editing format natively, not have to use a program-specific format (Illustrator, Kontour, Karbon14, anything) and then export to SVG. I want to work natively in SVG. With luck, this will let us do that.

There are some potential downsides, of course. Most notably, the risk that KDE will become like Mozilla. An all-XML UI, which while flexible also makes it considerably slower than just using compiled widgets. KSVG will have to be very very fast to avoid that problem, unless things are precompiled in memory cleanly.

Still, I can't wait. :-)

Why is SVG important to the desktop?

[stienman]

I suspect a number of people are wondering why SVG is important to the desktop. There is one major reason to have SVG as part of the normal program rendering. Several smaller reasons, too.

Objects can be clearly rendered in SVG regardless of the output device resolution.

We are seeing small 15" laptop screens with resolutions of 1920x1200. Soon we will have desktop monitors with higher and higher resolutions. This is because the profit margin in low resolution LCD monitors is quickly becoming very thin. Manufacturers are going to try and differentiate their products by touting the clarity and color rendition of better, higher resolution screens.

So the operating system designer doesn't have to

1. Create an icon for each resolution
2. Use icon scaling
3. And make many sections of code that will make sure the important things are on screen and usable.

Many applications could and should run well on a PDA (4", 200x320) a cell phone(1.2" 90x90) and a scientific visualization workstation (120", 6400x4000) without device specific code or modes.

The smaller reasons include much less data - if a graphics card rendered SVG, then the connection between the computer and the card could be slow and very long distance. Hard drives space isn't an issue, except in power-conscious embedded areas where smaller graphics files could make a difference.

Lastly, rendering speed improvements could be realized. Aside from dedicated HW doing the rendering, if the OS did it in a trusted manner then it could be faster than many libraries and/or programmer hacks. Programs could as a result be smaller, since they don't have to maintain as much graphics, layout, and UI information.

In short, there are many good reasons to include SVG in the lower system level - mostly looking toward the future of hardware, but when it's here, won't it be nice to be ready?

-Adam

I'm ekstatik

[Rosco P. Coltrane]

kde kan konker kountless desktops with fantastik new applikations like ksvg and kpart, but I really krave for a less krappy naming skeme that kould help even out the wear on my keyboard ...

very real way

[SuperBanana]

KDE 3.2 will be adopting SVG in a very real way

--Dateline, October 14th-- GNOME project team announces they will be adopting SVG in a very, VERY real way.

Seriously, people. Thesauruses are your friend, ok? :-)

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,

Re:SVG != resolution-independent icons

[stienman]

You would still have a need for different icons, depending on the amount of detail the interface is capable of rendering. A single SVG icon would be either too plain for a 1600x1200 screen or too complex for a 90x90 cellphone display.

Oh, come on. It's a simple matter to create a icon that is as complex as it needs to be (ie, you don't need a super complex icon for Staroffice) regardless of the output device.

It's then a simple matter of 'culling' the detail. on a 90x90 cellphone display, you simply don't render objects that are smaller than a pixel or two. In that case you end up with only the larger aspects of the icon. Furthermore, the device may avoid rendering gradients, going for a solid color, etc.

The designers ought to be aware of this, however, and make sure there are some larger as well as detailed aspects to every icon.

But the real idea behind an icon is that it is the same angular size relative to the distance to the human eye, regardless of the resolution of the display device. This means that the icon on a monitor 24" from the eye would be about 1" by 1" regardles of the resolution. Since the human eye has an inherent resolution limitation then certian details are not practical in the icon since they would not be resolved by the eye, even though the display may be capable of rendering them.

Similarily, a stadium size display need not render a lot of small details since the eye is more than 10 or 50 feet away, and, again, the eye's resolution wouldn't be able to resolve a detail that is only an inch large on the display.

-Adam