Slashdot Mirror
WVG : The New Scalable Vector Graphics
jafro_svg writes "While the press has discussed Microsoft's upcoming 'Sparkle' as a potential Flash-killer - the technology arena on which Microsoft's new technology is having the most impact is SVG. SVG (now a W3 standard for 3 yeras) was itself billed as a Flash-killer some years ago, and speculation about how it might be accepted into the mainstream for developers (i.e. incorporated into IE) now seems inevitable -- you see, Sparkle's real name is WVG and is 90% identical to SVG." Jafro_svg also points out this online SVG tutorial.
Umm, people, the reason this is important is because client-side apps will be using this to draw their interfaces. WVG is the new way to do UI in Longhorn, whether it's in the browser or not.
Looking at their overview, this looks a lot like their previous answer to SVG - VML.
VML tied into directx. They only mention that you cannot mix GDI and Avalon in the same window because WVG is hardware rendered through Avalon. Also sounds like directx.
The only major change was that in VML it always wanted a namespace defined for it to work - like IE didn't know what to do with a VML file. WVG seems like a different way to display for generic windows applications - not just web.
Looks like microsoft is innovating by repackaging an older product into a discription language that can be called by a standard win32 app. It would be interesting to see an open source toolkit that does the same thing as WVG, but uses open standards and remains cross platform.
When I looked into things last spring, I remember experimenting with a several small images (3-30k). I suprisingly found that the SVG versions were just as small as (and usually smaller than) raster versions, and that was without any form of compression on the XML. It all depends on what your specific content.
...so I feel obligated to link to the Mozilla SVG Project.
If you want to create SWF (Flash) animations, there are much cheaper alternatives to buying Flash from Macromedia. SWF is an open format, and there are other manufacturers of creation tools. Swish is one I've heard a fair bit about. Others are available for Tucows. You can even create SWF files from within PHP with the MING libraries. In short, I don't think SVG will replace SWF simply because of cost.
I wrote my impressions from Microsoft's Professional Developers Conference and the new technologies presented there in:
m l
http://primates.ximian.com/~miguel/texts/pdc.ht
There is a potential for XAML and WVG to become standards just because of the large deployments of these technologies.
Miguel.
So? SVG isn't a "Web Standard" either. It's an image format. The fact W3C are maintaining the standard is irrelavant. KDE (and others?) support SVG internally without having to butcher the standard...
SVG supports gzip. SVGZ files are efficient because verbose, repititious text compresses well.
Look at the filesizes in these examples. Betcha can't make PDF files that small.
So let me get this straight. Microsoft is taking a standard, modifying it slightly just for the sake of making it incompatible, and then foisting it upon all users and developers who use Windows, invalidating the 'standard'.
Yeah, I knew there was a reason we came up with the term "Embrace and extend"... Joy. I look forward to the mess this will create.
Random and weird software I've written.
It's definitely worth looking over. I had been checking out Sodipodi's last release last spring, but there still were enough rough edges to block my main needs. But with what was in CVS last month, they both jumped up to 'very handy'. And the Inkscape work has jumped things up even more.
Well, if you actually read anything about Longhorn, you would know that there is no difference between a native app and a web app in Longhorn. IE will support avalon rendering, so if you go to a website that uses MS's proprietary document/app format, you WILL see a Sparkle rendered page.
Read anything about it, does USING and developing on it count?
You are right that Web Applications will use also be able to use the rendering engine in Longhorn; however, you still don't get it.
You are taking about features of the distributed application model that allows web and client side applications to be synonymous to the OS.
The fact still remains that 'Sparkle' is the rendering engine of Longhorn, just as the GDI of Windows today uses a Bitmap based engine.
Using your analogy is ridiculous when you consider that Web pages of today are displayed in IE window on a Windows computer rendered as a Bitmap image. This is no different than it being rendered in the future as a vector image in Longhorn.
Using your messed up analogy you could also say that because the current Windows GDI uses DIB technology to display a Web Page in IE then Microsoft is trying to take over the JPEG and other Bitmap technologies. (Sound ridiculous yet?)
You are confusing the two concepts, and using that to establish that the Vector engine or Longhorn is designed to be a WEB standard.
Admittedly there is more to "Sparkle" than just the Vector engine of Longhorn by incorporating the UI in a XML style that is network friendly, but that does not mean it is designed to take over anything that already exists, it is simply just the evolution of display technology in Longhorn.
If you look hard enough, you will see that "Sparkle" has concepts from other networking GUI models as well, does XWindows ring a bell? Making an open light protocol interface for the Vector engine is a great idea, much better than shoving massive chunks of bitmaps over the network for remote applications.
- But again, this does not mean it is designed to replace the internet with a Windows only world - Microsoft is NOT that stupid, nor do they have that much control on the internet.
Actually I have realised we are talking past each other.
You are talking about sparkle and we are talking about WVG and XAML.
Sparkle won't be the only engine to read WVG and XAML (as I think I have shown with my links to the documents such as this one which interestingly references current failings in HTML as a reason for a feature in xaml) and so it is justified for developers of non-windows platforms to be anxious about whether they will be able to create program that can parse future data on the web.
Vector-based CRTs have existed. There are probably a few around in museums still.
Finally! A year of moderation! Ready for 2019?