Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI Graphics Software Linux

Major Step Forward For SVG in the Desktop 363

Posted by Hemos from the moving-things-along dept.
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."
This discussion has been archived. No new comments can be posted.

Major Step Forward For SVG in the Desktop More

Major Step Forward For SVG in the Desktop

Comments Filter:

  • odd (Score:2, Insightful)

    by pummer ( 637413 )
    Now, what is the problem with icons today??? They're ICONS. It's not like they're actual programs that matter! They're ICONS! C'mon!

    • Re:odd (Score:5, Insightful)

      by jordan_a ( 139457 ) on Monday February 03, 2003 @09:10AM (#5214770)
      Icons are only a small part of what SVG Graphics are about. However being the most common images used on the desktop it is a logical starting point for SVG graphics.

    • Re:odd (Score:2, Insightful)

      by olethrosdc ( 584207 )
      The SVGs would be most useful for widgets I guess. Now that I think of it, they would be extremely useful for widgets and buttons.

      On the other hand, the SVG would have to be yet another library to have installed on your system, with all the problems associated with having yet another library :/

    • Re:odd (Score:5, Interesting)

      by Proc6 ( 518858 ) on Monday February 03, 2003 @09:20AM (#5214826)
      Well dummy, its like this. The higher resolution the display you get, the finer detail images and video (some day) can get. Buuuut... the harder it is to see windows elements of fixed size. (icons) I run 1920x1200 on a flat panel, and when my father sits down in front of it, he has to squint to read the text and see the icons on the desktop. Ever seen 1600x1200 on a Dell Latitude notebook? Go find the IBM QUXGA 22" LCD panel that does something like 5000x3000 and tell me how big the icons on the desktop are. Its like clicking on dust.

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

      • Re:odd (Score:5, Insightful)

        by Lucas Membrane ( 524640 ) on Monday February 03, 2003 @11:38AM (#5215556)
        I'm a little ahead of the baby boom, so my eyes are a little worse than those of most people, but they are catching up. This is something that is long overdue and will be most valuable or just about essential as the demographic bulge moves into its later years. We can't go on creating every UI like it was designed by a 22-year-old with no idea that vision doesn't deteriorate for some of us. It's just about criminal that if you are having trouble reading the screen and go out and buy a better, higher-resolution monitor, everything gets harder to read.

  • Just more OSX themes. (Score:2, Insightful)

    by Sh0t ( 607838 )
    This will pave the way for bigger and better OSX clones! Honestly, do we really need SVG icons on the desktop ? All i do is click my icons, i don't need them to enlarge to 200% when I mouse over them or shrink to nothing when I click them. I understand the need for eye candy, which is cool, but SVG icons aren't on the top of my list. Eye candy ? www.sh0t.com/gnome.jpg Anyhow, it's an advancement nonetheless

    • Re:Just more OSX themes. (Score:5, Insightful)

      by rseuhs ( 322520 ) on Monday February 03, 2003 @09:09AM (#5214768)
      Unlike most eye candy, this makes the desktop faster, so I don't see anything wrong about it.

      Also, the more it will be used, the faster it will hopefully become available in browsers out of the box so we can finally ditch flash...

    • Re:Just more OSX themes. (Score:4, Funny)

      by Anonymous Coward on Monday February 03, 2003 @09:13AM (#5214784)
      You should look at the possibilities BEYOND icons...

      cat pr0n.gz | gunzip | svgviewer

      "mmmmm, scalable porn...."
    • Except OSX uses bitmap images for their icons (TIF, PNG), not vector graphics (SVG).

      Default icons are 128x128 pixels, but are usually displayed at 32x32. OSX just has a very good scaling algorithm.

  • This is a great thing!!! (Score:5, Insightful)

    by md17 ( 68506 ) <james@@@jamesward...org> on Monday February 03, 2003 @09:06AM (#5214749) Homepage
    Great work librsvg team!!! I look forward to the day when there is no more Flash because SVG is so well supported. SVG: XML based, open standard, w3c backed, blah, blah. I love it! SVG is the ISH!
    • 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.
      • You are wrong on two counts: 1. There is a full syncronization between animation and graphics in Adobe SVG Viewer. Adobe audio element works just like SMIL audio element with all synchronization stuff available for it. 2. There is already an agreement that it should be perfectly legal to embed SMIL audio element in and SVG document and it should work just the way Adobe audio element does now.

  • Stateful Icons? (Score:5, Interesting)

    by Masem ( 1171 ) on Monday February 03, 2003 @09:08AM (#5214758)
    Could this also be used to build 'icons' with stateful representations of the objects they are supposed to represent? For example, instead of just 'empty' and 'full' for Trash/Recycle, could you have folders icons that have 'empty', 'sparse', 'full', and 'stuffed'? Or icons that reflect the read/write nature of the folder with respect to the user? Or even more down the road, icons that aren't pointing directly to files/folders but as system objects (as say down the /dev tree), such as a clock, a CPU meter, etc...? Yes, we have that functionality through many means, such as WM's dockapps, or by using shaped windows to simulate that. But if you look at the Mac OS X Dock, or the various things you can do with ObjectDesktop by StarDock systems on the Windows side, they reflect the ideas that I'm thining about here. Sure, it's nice to have, in WM , the status of my system along the right side easy to see, but I'd like it better if I could have a better control over how those are appearing on my desktop, and if I could make them true icons, draggable and placable whereever I want, that would be great.

    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.

    • Re: Stateful Icons? (Score:5, Informative)

      by Anonymous Coward on Monday February 03, 2003 @09:17AM (#5214808)
      This functionality is already in Nautilus. They're called emblems. You have read-only emblems, Music Folder emblems, etc. It supports both PNG and SVG emblems.

      Maybe Konq has this too, but i haven't used it in i-dont-know-how-many years, so i dunno if it does.

      • Re: Stateful Icons? (Score:4, Interesting)

        by Textbook Error ( 590676 ) on Monday February 03, 2003 @09:33AM (#5214884)
        Same idea in Mac OS X - which calls them "badges". The API lets you composite one icon reference on top of another and draw it as a single entity (or to find out if an icon reference is actually a composite).

        Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything. At least for the tasks icons are typically used for. Anything larger than 128x128 is turning into a picture rather than an icon (yeah, you could use the same format for both, but why bother - 99% of the time an icon is just blitted to the screen or used for hit testing, both of which an 32-bit pixmap is ideal for).

        • Re: Stateful Icons? (Score:5, Insightful)

          by IamTheRealMike ( 537420 ) on Monday February 03, 2003 @10:13AM (#5215048)
          Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything.

          Covers everything at this time. Max resolutions have gone up year on year, but most people don't use the full capabilities of their card/monitor because the screen elements become too small. So having a resolution independant desktop would be a good way of solving that issue (though obviously you still get these issues with the web).

        • Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes)

          So is the scaling algorithm more or less expensive than the SVG renderer? What about CPUs with no hardware floating point (goes for both SVG and bitmap)? What about scaling to print?

        • Re: Stateful Icons? (Score:5, Interesting)

          by ajs ( 35943 ) <{ajs} {at} {ajs.com}> on Monday February 03, 2003 @10:58AM (#5215338) Homepage Journal
          The main reason to do this is rendering speed. Storage size is also smaller, but really you care about the rendering speed of having 5 apps open, all of which use dozens of icons (I'm running galeon, and I count 16 icons in it alone... galeon tends to be light-weight when it comes to baubles compared to say, a spreadsheet).

          People complain that GNOME and KDE are memory-hogs and slow, but realistically, most of the overhead is in things like pixmap storage (not going to go away with SVG or PNG, since both have to be rendered down to an X Pixmap). Beyond that, you have to start hacking away at every bit of performance and memory use you can find. This is one such.

          I assume that KDE already has or is working on SVG too. It's a logical step. Heck, they *could* just use this lib if they don't already have one.

      • Re: Stateful Icons? (Score:3, Interesting)

        by Speare ( 84249 )

        They're called emblems.

        While emblems affixed to icons are nice, that's not what the parent post was talking about.

        With stateful alternative artwork, a folder icon could appear open or closed or locked or zipped. A trashcan could appear lidded, unlidded, bulging or empty. Emblems don't do that.

        With stateful procedural rendering, a folder icon could appear tinted or shadowed or translucent or scaled to highlight different ownership or age or some other user-defined categorical criteria. Emblems don't do that.

        With stateful procedural animation, a folder icon could glint, shudder, bulge, wave or otherwise animate when the mouse floats over the icon, or when objects change status in some way.

        Further, emblems should be able to do all of these things independently from the icons themselves: the icon itself may glint and bulge while the emblems blush or twist.

        Sure, bad themes would be a distraction, but good themes could provide a lot richer interface to a very dense data space. This is true of Flash, of Skinnable applications, and of GUIs in general.

    • Re:Stateful Icons? (Score:3, Insightful)

      by jonr ( 1130 )
      BeOS did something close to this. Although vector-based icons are more suited to this.
      I could start ftp download and then just keep an eye on the file's icon in the Tracker for progress... Very useful.
      J.

  • great lib name (Score:5, Funny)

    by RobertTaylor ( 444958 ) <roberttaylor1234 AT gmail DOT com> on Monday February 03, 2003 @09:12AM (#5214783) Homepage Journal
    gdkpixbuf

    That looks like someone headbutted the keyboard...

  • Once again... /.'ers rally against the cause... (Score:5, Interesting)

    by Anonymous Coward on Monday February 03, 2003 @09:16AM (#5214802)
    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.

    • Re:Once again... /.'ers rally against the cause... (Score:5, Informative)

      by IamTheRealMike ( 537420 ) on Monday February 03, 2003 @09:32AM (#5214877)
      One of the big reasons I like OSX (and I do not own a Mac, FYI) are the scalable vector icons

      Bzzt, wrong. MacOS does not have any SVG or vector icon capability. It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256. That means, no resolution independance for you - ie in a true res independant desktop doubling the resolution just makes things sharper, as opposed to smaller.

      Note that this implementation probably won't do MacOS style fast zooming (not that it's all that useful anyway). For that I think we have to wait for XSVG, which actually integrates with the X server and can offer hardware accelerated SVG rendering (note that librsvg is faster than libpng in some cases).

      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.

      GTK already supports SVG themes, but I think a bit more work is required to make them really usable and realistic.

      • It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256

        They're 128x128 actually.
      • nice, but they can't go any bigger than 256x256

        And I've been trying like mad to get them to change this. All I want is a single 1024x768 icon for Emacs on my desktop.

      • (on 'the cause' - no kidding, eh?)

        Note that this implementation probably won't do MacOS style fast zooming (not that it's all that useful anyway).

        I think zooming may play a much more important role in future GUIs. While the Dock's little parlour trick has limited functionality - apart from being a nifty demo - in its current form, I can see all sorts of situations where you could impart a huge amount of information through a 'zoom-up'.

        For example, those icon badges mentioned before. I find myself wishing for both more informational icons, and a keyboard-activated zoom focus. The Mail icon shows you how much mail you've got, that's nice... but I want more info. It would be great to mouse over the icon and have the connections/progress listed. Or, roll over the clock and have a calendar zoom out at you like a springloaded folder... putting itself away when you roll away. This gives you a really high amount of information density in a small amount of screen space. The SVG icons are great, the only problem I can see with them is for photographic material. Postscript-type files are fantastic and small for line art/gradients, but if you tried to vectorize a photo of Linus' head it would be a very large icon data-wise... much larger than a standard bitmap would be. I suspect this is why the OS X team went with the vector-transformed large bitmaps (someone else pointed out - or was it you RealMike? - that 256x256 icons are good for now, I'd respectfully point out that the 32x32 icons are still appropriate for most modern resolutions... 256 pixels will carry us well into the next 8 years barring otherworldly jumps in display resolution.)

    • Here's the algorith.

      if (new || different) { sucks == true; }

      I think that you are exactly right. A GUI is all about offering the user a lot of information quickly and in an easy to understand manner. This will be a move forward. You will be able to create stateful icons that give you a lot of information at a glance. That is what it is all about.

      I know that there are a lot of proprietary ways to do this right now but moving towards SVG is a step forward. As one user pointed out, it will allow users to make their own custom icons with custom functionality without really having to program.

  • A better way to clone the OSX look and feel? (Score:5, Interesting)

    by image ( 13487 ) on Monday February 03, 2003 @09:19AM (#5214814) Homepage
    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.

    • Re:A better way to clone the OSX look and feel? (Score:5, Insightful)

      by GauteL ( 29207 ) on Monday February 03, 2003 @09:55AM (#5214969)
      You seem to be under the impression that the OSX-icons are SVG. This is not true. They are just resource forks containing several different sized icons so that they seem to scale "magically".

      They might be drawn with Vector based drawing, but they ARE converted before used as icons. KDE does the same thing. The excellent Crystal Icons are SVG-based, but they are converted to PNG for KDE, hence the incorrect assumption that KDE supports SVG. KDE is supposed to get SVG-support in KDE 3.2.
      • > You seem to be under the impression that the OSX-icons are SVG. This is not true. They are just resource forks containing several different sized icons so that they seem to scale "magically".

        Wow. I was under that impression. Thanks for clearing that up! And I have to give credit to Apple for doing an amazing job with their scaling interpolation algorithm. Certainly fooled me.

        (PS, moderators -- mark the parent up as insightful.)
  • XML is a great thing. It could lead to the end of diferences in the look between toolkis and desktops. Most people complain about choise when desktops are made to look the same way, but acctually, this is choise. Today you can't make a gnome app use the file open dialog from kde. If QT-Designet can load glade files, why trolltech and gtk team work on a kind of wrapper for the call of signals, so if the programer want, he choose to load a XML file that contains the visual choosing what widget will take it? This would be not mandatory of couse, if people don't want, just don't use this, and keep working qt and gtk apps as now. But it would be very cool if I could load gimp saying to it: use qt instead of gtk today, thanks. :)

  • Finally, great news for users :) (Score:5, Interesting)

    by CheeseCow ( 576966 ) on Monday February 03, 2003 @09:21AM (#5214830) Homepage
    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.

    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! :D
    • amen to that

      I'm running 2048x1536 on a 22" & I'm very happy that for the first time in my computing career instead of using the space to display somewhere near a useful amount of workspace I can actually keep the workspace the same size and turn up the font size.

      Running a term where the chars are 1cm high but I can still get 100+ columns is a godsend.

      Big fonts rule and all the better that I have a dual head system and I dont have to squint at IRC to read the text. I can have it at 22pt and read it from anywhere in the room.

      • Re:Finally, great news for users :) (Score:4, Insightful)

        by tempfile ( 528337 ) on Monday February 03, 2003 @11:44AM (#5215589)
        In a perfect world, you wouldn't have to increase the font size when your resolution grows. Instead, you'd tell the computer about the resolution and it would adjust the font rendering accordingly. Remember that pt is an absolute measure (1/72 inch), as in "Computer, make that font 22pt tall and I don't care how many pixels you will use".

        It has been a problem for a long time that fonts would scale up with increased rendering resolution, but icons wouldn't, destroying the visual composition. SVG can definitely make that better.

  • Mindblowing (Score:5, Interesting)

    by CoderByBirth ( 585951 ) on Monday February 03, 2003 @09:29AM (#5214867)
    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.

  • Corresponding Browser support? (Score:4, Interesting)

    by brianjcain ( 622084 ) on Monday February 03, 2003 @09:30AM (#5214870) Journal
    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.

    • Mozilla (Score:4, Interesting)

      by Anonymous Coward on Monday February 03, 2003 @09:50AM (#5214944)
      Mozilla has a native SVG project [mozilla.org] 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?

      • Re:Mozilla (Score:4, Informative)

        by IamTheRealMike ( 537420 ) on Monday February 03, 2003 @10:00AM (#5214986)
        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?

        Not really. A better fit would be Xr - librsvg does the rendering but Mozilla needs to do it itself for good integration. Using Xr however in place of libart would provide a better backend.

  • Svg Developpement (Score:2, Interesting)

    by Sepper ( 524857 )
    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 [sourceforge.net] 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 [w3.org]. 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...

  • Good news, but it would be much better... (Score:4, Informative)

    by ubiquitin ( 28396 ) on Monday February 03, 2003 @09:48AM (#5214937) Homepage Journal
    ...to have a really good SVG editing tool. GIMP 1.3.1 shows that some GNOME developers have put some serious thought into Bezier editing tools, but nothing that has been released as a standalone vector editing app. killustrator, sodipodi and similar apps just aren't ready for prime time. If you're willing to spend the time to use it, the GIMP is really about as powerful as photoshop. Unfortunately, there is nothing in the open source world which is anywhere near as close to Adobe Illustrator functionatlity.

    Worth noting that NeXT had display Postscript robustly implemented and SGI's window manager also had scalable fonts, but neither of these OS or GUIs are around today. If there's a lesson to be learned here, it is that the UI isn't significantly improved by scalable vector graphics. SVG is an improvement but not one which will make any competitive difference. Fortunately or unfortunately, the 25 year history of user interface points us in a different direction.
  • How does librsvg compare to ksvg? Which is faster, more compliant, more powerful etc?

    • Re:One quick question (Score:4, Informative)

      by tjansen ( 2845 ) on Monday February 03, 2003 @10:34AM (#5215184) Homepage
      AFAIK it is more compliant at the moment because it supports more SVG features. But librsvg is just a static renderer, whereas KSVG aims to offer a complete DOM model to KJS, KDE's JavaScript engine. This allows Macromedia Flash-like interactive animations using SVG+JavaScript.
  • ... is that it swaps memory for CPU : SVG images (and in general vector-bassed images ) require less memory to be stored, but more CPU to be recreated.
    It's not clear to me how this could result in a faster desktop, except that it should cause less swapping, and that modern CPUs have power in excess (but it could be the same for the RAM, except that desktop machines are often sold by default with inadeguate RAM supply, mostly for commercial reasons).

    The real place where vector-based graphic would be useful is the Internet. Less memory would mean less bandwidth required to transmit the image, and the greather CPU usage shouldn't be noticed, given that when you are surfing you don't care if the other activities on your PC (if any) are a bit slower.
    But I wonder if SVG would be much better than image compression in that sense.

    • I was wondering about the speed thing too - it's hard to get faster than blitting a bitmap onto the screen, especially since modern graphics hardware has umpty-jillion hardware optimizations.

      The advantages of resolution-independent scaling, though are huge - and I can see "faster" meaning "renders faster than a scaling algorithim for a bitmap"

    • Re:SVG trade-off .. (Score:5, Interesting)

      by Knobby ( 71829 ) on Monday February 03, 2003 @11:12AM (#5215418)

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

  • What's going on? (Score:5, Interesting)

    by Tyreth ( 523822 ) on Monday February 03, 2003 @10:15AM (#5215058)
    Why are there so many people complaining about "what's the point of SVG" or "what a waste of time" kind of arguments. What's the issue here?

    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:

    • Prettyness - this is the most obvious. Most people like something that looks good! Sure, it may not have an obvious practical advantage, but humans are naturally attracted to things that look good, as opposed to a website with black background, red/yellow flashing text with images with white backgrounds. There may be something deeper to this - when something looks professional /pretty, it feels easier to understand. The less attractive it is, the more complex it feels. Quite simply, the more something feels like sphagetti the less our mind will be able to comprehend it and move on to newer things. The neater something is and the more we comprehend it, the easier we will find to move on to something new.
    • Resolution - been mentioned earlier. Different resolutions require different font sizes. This means that the artist can make an icon that will be useful from now until the time computers go primarily 3d. They don't need to anticipate resolutions of the future, their work will scale seamlessly.
    • Speed - this is a speed improvement. The more our code is improved and sped up, the more integrated it can be. This is just one of many enhancements to Linux that make community software that bit better.

    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 matching for scalable graphics (Score:3, Interesting)

    by more ( 452266 ) on Monday February 03, 2003 @10:22AM (#5215113)
    It is nice to have the sharp features aligned with the pixel boundaries while still maintaining approximately the geometric relations. Perhaps a deformable match of the high frequency features with the pixel boundaries could be a solution for showing glyphs most accurately on pixelized displays?

    Deformable matches are used in advanced medical applications between 3d volumetric images: CT, MRI, PET, etc.

  • Excellent... (Score:3, Insightful)

    by Anonymous Coward on Monday February 03, 2003 @10:24AM (#5215128)
    I seem to be alone here as the only person who actually thinks this is a fantastic idea...

    The whole point about SVG is that they will render nicely whatever the screen size... This isn't only relevant for big screens. This means that my iPAQ's tiny little 320x240 screen won't have to be eaten up by huge bitmap icons.

    The SVG stuff should tie in beautifully with the sub-pixel rendering in X.

    Congratulations to the author(s) for their great work..

    Looks like linux just gained yet another feature that windows is lacking.

    Well Done :)

  • Display SVG (Score:5, Interesting)

    by DrXym ( 126579 ) on Monday February 03, 2003 @10:25AM (#5215131)
    Screw the icons, how about a complete display SVG engine akin to Display Postscript / Aqua?


    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.

    • SVG vs. PNG (Score:5, Interesting)

      by daVinci1980 ( 73174 ) on Monday February 03, 2003 @12:40PM (#5215846) Homepage
      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.

      • Re:SVG vs. PNG (Score:3, Interesting)

        by scrytch ( 9198 )
        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.

        Except that most 3d cards will rasterize them internally and not have to a) use main memory, b) transfer main memory across the bus, or c) involve the CPU in a meaningful way. If a good SVG to OGL or D3D mapping can be found, you most certainly can render it faster than a PNG.
  • Thing is, frequently you want a loss of quality when you scale an icon. Who cares about all the pretty brown crinkles in the Gnome foot icon when it's at 12 x 12? They won't read like crinkles, they'll read like a muddy mess. A simple outline is probably best at that size.

    Now, a format that defines a priority heirarchy among the vectors on the image, and a scaling factor at which size various low priorities of vectors are not rendered... That might be very, very useful for icons.

  • Patent issues all resolved? It _appears_ so... (Score:4, Interesting)

    by dwheeler ( 321049 ) on Monday February 03, 2003 @10:39AM (#5215221) Homepage Journal
    At one time, I recall that there were some serious patent issues with SVG. Basically, SVG wasn't really an open standard, because it was patent royalty encumbered - giving an automatic disadvantage to those who weren't patent holders, making it impossible to implement using open source software / free software, and discouraging implementation in any place where expenses have to be kept down (including some small businesses and mass market devices).

    According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l [w3.org] and http://www.w3.org/Graphics/SVG/Disclosures [w3.org], 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.

  • The best demo i found. (Score:3, Informative)

    by Jeedo ( 624414 ) <asdfasdfasdfasdf ... fasdf.com.is.org> on Monday February 03, 2003 @11:07AM (#5215387) Homepage
    Adobe has made some nice Demos [adobe.com] of the capabilities of SVG especially things that would previously have been only possible with Flash

    Although, being a windows user i could only view it using the Adobe SVG Viewer which only works in IE, any of you have an idea of how to make it work under opera7 drop me a line:)

  • Remember the NeXT... (Score:3, Interesting)

    by kahei ( 466208 ) on Monday February 03, 2003 @11:08AM (#5215394) Homepage

    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.

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Close