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 ;)

And Mozilla?

[PipianJ]

So Konqueror will have decent SVG support now.

When are we going to get decent working SVG support for Mozilla (and Phoenix) in X then? Last I checked, we're still stuck with libart (which can't be officially included in Mozilla thanks to the lack of a tri-license) and the infamous Bug 111152 was still open...

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.

Somehow, this came to mind ...

[John Jorsett]

Seeing as how the VP is such a VIP, shouldn't we keep the PC on the QT? 'Cause if
it leaks to the VC, he could end up an MIA, and then we'd all be put on KP.

Re:Somehow, this came to mind ...

[jazzmans]

Goood Morning VietNam!

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. :-)

Re:Wicked cool!

[Adolph_Hitler]

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. Yeah just like having more than 64 megs of ram is overkill, I mean who could ever use more than 64 megs of ram? Just like the 3dfx Voodoo 3 was overkill, I mean who would ever need a new video card after this? I mean the 1ghz pentium, its definately overkill, who would ever need more than 400mhz Pentium 2? I think what Linux needs is overkill if its to compete with the other OS's which are more modern. OSX and Longhorn will be overkill, but people want overkill and if you are to compete with overkill then you must overkill the overkillers. Personally I want an SVG interface, I like the idea of not having to set my resolution, I like the idea of having perfect quality text, I like the eye candy of OSX, and if i have the video card to do this with absolutely no hit to speed, why shouldnt it be done? If I dont like it I'll turn it off and I'll still have a faster system which uses less ram than a pixel based GUI. Please go into details on why SVG for the entire interface would be bad. Just because you won't use it is not a good enough reason, you need facts not opinion.

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.

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:Why ECMAScript? Choose Python!

[spektr]

Ruby is the best language to use! Down with Python, up with Ruby!

Kids, what's up with you - fighting over what's the best language is stupid!

Love is stronger than hate.

So let's invent a new language together!

SVG != resolution-independent icons

[mangu]

To all the people who have been saying that SVG would make it unnecessary to have different icons for different resolutions, I must say that icons are not thumbprints. 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.

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

Re:SVG != resolution-independent icons

[crisco]

Your first two paragraphs remind me of why font hinting is required. Fonts are resolution independant graphics, yet they require help with rendering at low resolutions to maintain readability.

Does SVG have any simple means to create a 'hinting' system?

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: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.

Why XML?? Just why?

[ebyrob]

Can somebody tell me why SVG would be implemented using XML? I mean .png, .gif, and .jpg don't use verbose ascii storage formats do they?

What ever happened to compact binary image formats?

Re:Why XML?? Just why?

[sorotokin]

The main reason it is XML is so it integrates well with other W3C standards: SMIL, XHTML, XSLT, XSL:FO and CSS. Actually SVG itself relies a lot on these formats. For instance, styling is done with CSS, SVG can easily be generated with XSLT, a lot of SVG text layout attributes came from FO and SVG animation is basically an integration with the SMIL animation module. SVG is not supposed to do everything by itself, and, for instance in Adobe SVG Viewer v6 preview you can embed a pieces of XHTML in SVG and SVG in XHTML.

And verbose it is not. Actually after gzip compression (support for gzip is mandated by the spec) it is one of the most compact graphics format.

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 ECMAScript? Choose Python!

[Jondo]

Ridiculous? I think not. Have you ever actually seen SVG document that includes embedded Python? The KSVG team hooked in ECMAScript for the simple reason that it is actually used in real SVG's from the wild. IIRC Adobe's SVG impl. also does javascript, for the same reason.