Slashdot Mirror
Major Step Forward For SVG in the Desktop
Ur@eus writes "SVG the w3c format for Scalable Vector Graphics is seen as many as the future of desktop icons as it allows for scaling icons etc. without loss of quality. Dominic Lachowicz has been working hard on fixing bugs in librsvg over the last few days. The result is that librsvg now renders all available SVG icons perfectly.
Not only do it render them, but it renders them faster than libpng renders the same images in png format.
Together with the gdkpixbuf plugin librsvg offer it means GNOME 2.2 will be able to use SVG images not only for icons or desktop backgrounds, but also for the GUI widgets themselves and the graphics of the window manager.
Dom's announcement can be found on the librsvg mailinglist. The librsvg site also offer a GNOME 2.2 metatheme using mostly SVG icons including a nice screenshot."
IF SVG supports raster (pixelbased) graphics, together with the vector graphics (as textures or something), this could be really useful. An ultimate graphics format, the holy grail...
As for not being needed on the desktop. Optimizations are *always* needed and useful. Also, this can finally mean truly resolution independent graphics. Simply know the dpi of your screen and all will always be the same size, independent of grannys old 640x480 and mine 1280x1024...
Even more so, using XML and SVG, it would be very easy to create additional icons without a lot of programming behind it. You may need to a SAX reader to take the stateful information into some form, but after that, it's just XSLT transformations into SVG, and voila, you have an easy way to make cool meters/icons.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Jeeeze, just reading a few of the first posts on here you'd think that SVG icons were the end of the world. Nothing could be farther from the truth...
One of the big reasons I like OSX (and I do not own a Mac, FYI) are the scalable vector icons. We've had vector based fonts for quite some time and you'd be hard pressed to find anybody out there who would rally against the scourge of vector fonts. For crying out loud... I believe it's KDE that has font anti-aliasing. I am sure we all have seen WindowsXP's "clear type" font smoothing. Anti-aliased fonts work pretty damn well and look absolutely super!
Having the same capability with something as lowly as desktop icon is amazing! The next logical step is UI widgets and other elements of the desktop.
As more and more LCD and other high-quality displays become the norm (many laptops feature 1400x1050 or 1600x1200 displays these days), not only are scalable fonts and UI widgets neccessary, there is an inherent human aspect to having a computer interface with the same perceived clarity of the real world.
I think this is a fantastic implementation of vector graphics. I only hope that we can soon have entire UI's based around scalable graphics as well.
Right after OSX came out, I remember downloading a GTK and Gnome theme for my Linux box that copied the look, if not feel, of OSX. If I recall correctly, that theme was yanked by Apple's lawyers.
Since then I've started running a OSX box as well, and have to admit that I like the look.
Now I wonder -- would it be copyright infringement to write a script that extracted all of the SVG icons from a MacOSX box, copy them to a GTK theme directory, and run them on Linux? Thus the distributed theme itself wouldn't have any of the Apple look -- it would simply have the skeleton. The actual artwork would be copied by the end user in the privacy of their own home or office directly off a OSX box.
The second possibility for this is to be able to run, with almost the exact same look, GTK/Gnome apps on directly on OSX (Apple's release of X11 really is amazingly well done, btw). The X11 integration still wouldn't be perfect of course (apps still have a hard time mimizing to the Dock), but it would be a visual improvement. Or even integrate the ability to search a file's resources to get the SVG icon and display it in Nautilus by default.
In any case, librsvg sounds very promising. I'm impressed.
SGI's Indigo Magic desktop has done scalable vector icons forever, and its beautiful. Not only can you set the standard icon size but they put a handy thumbwheel in the "explorer" window to let you zoom in and out of your files.
Don't knock it till you've tried it. :)
I'm Rick James with mod points biatch!
This is excellent news. After getting a new monitor that does 1600x1200, I found those tiny icons a bit hard to click at times. But now, I can run whatever resolution I want, and the icons will just look better & better.
:D
Heck, now the word "resolution" will start to have meaning! Instead of getting more small icons on your screen when going from 800x600 --> 1600x1200, you could get more detailed ones. And if it renders faster than PNG images, then we can have both great looks & high speed. Way to go!
I really think that scaleable icons are gonna be THE killer application of tomorrows operating systems.
Seriously, why not go all the way and question the whole concept of icons?
They could be allowed more degrees of freedom in their representation of a complex data object. Consider a 3D spinning folder icon, which somehow gives you an idea of how much data/what type of data is contained in the folder.
Now THAT would be neat.
So can we expect similar native SVG support from our favorite gratis and libre browsers (Mozilla, Opera, et al) soon? I think it's only been available via a plugin before.
Yes, but wouldn't it be nice to have more scaling choices than large/medium/small? There's more to SVG than just scaling graphics anyhow. Serialization is another goal of svg, hence you may be seeing the beginnings of webservices dedicated to serving up icons, animations, etc... XML and it's cooperative technologies are evolving rapidly.
SVG puts powerful non-proprietary (bye bye gif) graphics capabilities in the hands of the xml architect. It fills a necessary gap in the XML arsenal. As the other technologies evolve, it's benefits will become more readily apparent. Imagine an XSL transform capable of transforming an XML document containing data into a graphical representation of itself...
Programmable content can be embedded as well in the form of applets and XHTML objects. Apache's Batik project is a good example of what you can achieve. Batik can be found here.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
Nice to see progress being made in this direction...
For thos who do not understand the value of making Svg work on the desktop, it's because you never worked with SVG before.
I've worked all summer long on a job where i had to make a (sacled down and very acurate) map available via web... and it had to be interactively linked to a database...
Now with fixed image this could have been a real pain, but once the map had been transfered from autocad, it was a simple matter: the text in tha map was clickable!
(well, i did have to write a script to build the Svg from a DXF file and it really needs to be cleaned before i post it)
The biggest problem i had to face was the fact that not a single svg viewer passed the W3c Test. The best one i had at the time (The Adobe SVG viewer) was not capable of anchor viewport (ie, using wahtever.svg#viewportdef to automagicaly load the viewport 'viewportdef')
I just wish the format could be more popular... it could the next flash...
I live in Soviet Canuckistan you insensitive clod!
I don't see that it makes much sense. after all 16x16 or 32x33 icons have been around fr a long time. they're even-byte things and easy to handle. and they're quick
And so are SVG icons - a lot of the current SVG icons are quick to load (requiring considerably less memory to describe the icon than PNG) and quick to draw with this fast renderer. But that is ignoring the most useful part of describing your screen using vectors, splines, etc. - rescalability. We're all used to being able to switch monitors with different DPI and still have the same physical size font on the screen (so that 10 pt is 10/72 inch high regardless of screen dpi) and it's useful to be able to have icons which behave in the same way.
isn''t a desktop all about making a useful user experience? if I wanted gigantic icons I'd have gigantic icons, and I don't. It seems like extra complexity just for a coding exercise.
For people with normal eyesight, standard 16x16 or 32x32 icons are going to be fine. If you suffer from poor eyesight, being able to have fonts and icons at say 4x magnification is extremely useful. And a big part of the GNOME2 architecture is strongly accessibility orientated so this is a useful part of the puzzle.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
The thing about scaleability of vector graphics (including SVG) is that the scaling works great if your are making the graphic bigger. However, if you want to make the graphic smaller you could have trouble. The problem is when you start to get to a small size the stroke thickness of the vectors cease to scale at some point thus distorting the intent of the graphic artist who designed it. For example, say you had a square with a black line that was 20px x 20px and the stroke of the line was 1 pt. If you cut the size in half to 10px the stroke should scale to .5pt (roughly half a pixel). So the problem becomes, how do you render half a pixel? You anti-alias it that's how. Unfortunately this would lead to 'blurry' looking little icons and mine eyes are sore as it is! ;)
I'm not saying that SVG is bad just that the scalability is not never ending and for small icons this may not be a good choice. It is also not likey SVG could allow you to 'design one l33t icon for all resolutions!' because of these issues.
Mozilla has a native SVG project that's been around for awhile.
I've always thought this would be the coolest thing ever: native SVG in a browser. I've thought of all sorts of great applications of this idea--I do mostly statistical analysis and to be able to put all the output, graphics and everything, into one file in a open, standard format that's read by a browser sounds wonderful.
The problem as I understand it is that the SVG library Mozilla currently uses has a license that's incompatible with the Mozilla license. Mozilla native SVG is available in a separate download and has some functionality, but not anywhere near all of it. I've always thought it seemed a bit strange that someone couldn't find a Mozilla-capable SVG library, or that it would be that difficult to build one (I would help, but I just don't have anywhere near the expertise necessary).
So, this stuff about Mozilla native SVG may seem offtopic, but it's really not, in a way: does anyone know if the library used for the SVG icons has any utility for Mozilla SVG or other open source browser-native SVG projects?
Funny how you mention half-blind.
SVG is one of the few 'imaging technologies' that has very good support for accessibility. Each drawn object can have a title and a description, so whereas you see a "stuffed garbage can", the braille user-agent would output the desc text: "Garbage Can containing more than 1 MB of trash".
SVG could also be used for an org charts, and instead of having a long 'alt' tag would probably be out of sync with the 'gif', the blind user would be able to read the contents of each box, and depending on how the SVG is structured (with groups and defs), even get an idea of how the boxes are related.
Also, SVG supports CSS, so you can have different stylesheets for different media (screen, printer, cell-phone-screen, and even braille and audio).
As far as an imaging technology goes, since it's just another XML format, you can grab an XML document (say in the Weather Observation Markup Format) and use XSLT to output a nice SVG graphic showing the weather. (In fact, that's one of the example used in O'Reilly's SVG Essentials).
I've just started using SVG (with Python) as a way to transform map data from the US Govt and make nice little SVG maps for my browser (kind of like a hand-rolled Mapquest).
Programmers familiar with XML will be able to make some neat (albeit very ugly) stuff. Designers who know the fancier drawing tools will be able to make some pretty nice-looking stuff. Put 'em together and you can have some nice smart graphics. Will it replace flash? Who knows.
My father is a blogger.
I can't believe people here have so little imagination. It's almost like they are posting just to get modded up for having a 'radical' opinion. I mean, come on, what's the problem with SVG? It's not like the time spent coding on it is going to mean KDE3.2 will be delayed a month, or that Gnome will have more bugs. This is just one of the many enhancements that make Linux, and software in general, nicer. We should be talking about the fun things we can do with SVG, or the improvements that could be made, or any encouraging notes on it. Not about whether it has a point at all.
Let me illustrate some points for the creatively challenged:
So, onto something more positive: what's the state of SVG in KDE? I really enjoyed it in Gnome 2 for the time I used it, but it was a bit slower when they got large. These speed improvements are certainly good news.
Deformable matches are used in advanced medical applications between 3d volumetric images: CT, MRI, PET, etc.
-- Imperial units must die --
If this lib as fast as it claims (at rendering though I doubt parsing), then why not? Windows and other elements in the display would break-down into SVG commands that would be rendered as required. Perhaps it would prove a very efficient way of presenting a remote desktop too rather than sending down bitmaps like VNC does at present.
According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l
and
http://www.w3.org/Graphics/SVG/Disclosures,
this appears to have been resolved to permit
royalty-free use.
If this is true, that's a real victory for the new W3C policy (and for the world in general). Thanks to all. Please let me know if I'm misinterpreting something.
- David A. Wheeler (see my Secure Programming HOWTO)
Remember how the NeXT boxes had postscript displays? Whatever needed to be drawn on the screen was expressed as postscript, and the display was a postscript renderer. It worked beautifully.
SVG is much more powerful (for desktop things, not necessarily for printing/typesetting things) than postscript. I think this is an excellent step.
Whence? Hence. Whither? Thither.
I'm not so sure why it would be faster to render the SVG and display the PNG (which needs to be decompressed), but keep in mind that it may depend on the test platform. Under Mac OS X 10.1, a lot of people were using a little command line hack that compressed the frame buffer. The memory bus was a bottle neck, and it was faster to compress and decompress the frame buffer than it was to move the uncompressed frame across the bus.. Just a thought.. CPU cycles are cheap, improve the memory system is not..
I read this claim again and again, and it still doesn't sit well with me. I worked on a vector-based rendering engine for awhile (in fact, the fastest vector-based rendering engine [begins with an f, ends with a lash]), and there are certain limitations that cannot be overcome.
When it ultimately gets down to it, a PNG file is a compressed bitmap. There is a fixed cost to rendering it, which can be expressed as an amortization of the dimensions of the image. Its just like fill-rate on a 3-D card.
When rendering any vector format, there are many dependencies. Is AA enabled? Which AA algorithm was used? Are they using a scanline renderer, or actually rasterizing each vector regardless of its impact?
The same reason which allows SVG to be faster than PNG rendering is the same reason that other cases will be radically slower: rendering each vector disregards the size of the image being rendered. How can this make it slower? Imagine an image filled dozens or hundreds of times with the same vectors that fill the image completely. Suddenly, we're not having to fill a rectangle, we're having to fill it multiple times in comparison to the png drawing in the same space. And the problem gets worse the larger the destination size.
Using a scanline renderer for vector based graphics has a much better cost comparison to png format, but it will always be slower as ultimately bitmaps can be embedded within vector formats.
As a simpler analogy; the vector graphics are to the transformation pipeline or a graphics card what bitmaps (and pngs) are to the rasterization on the video card. Transformation without rasterization is meaningless, and therefore always going to be slower.
I currently have no clever signature witicism to add here.
I look forward to the day when there is no more Flash
You may be waiting for something else then. While SVG supports animated vector graphics, there isn't anything in the spec for syncing audio to the graphics. I believe Adobe's plug-in has extensions for adding a sound clip, but still no way of syncing this up with what's happening in the animation.