Lightweight C++ Library For SVG On Windows? 130
redblue writes "I would like to display vector graphics in my Windows C++ programs with minimal system requirements. Some of the possibilities are: 1. Enhanced Metafile Format format/EMF+, 2. Flash/SWG, 3. Silverlight/XAML, 4. SVG. The non-open proprietary nature of #2 & #3 make them unattractive. Since EMF+ is not amenable to easy editing, it leaves SVG as the only format worth pursuing. The trouble is that the major vendors have a lock on the market with their proprietary formats; leaving SVG high and dry with no easy native OS support. At least not on Windows. From what I could learn on the intertubes, Cairo is the best, if not only, reasonable system that may enable compiled SVG support. Unfortunately, AFAIK, it comes with a price tag of >2MB overhead and the C++ bindings are not straightforward." Read on for the rest of redblue's question; can you improve on his home-brewed solution?
"In a flash of the NIH syndrome, I rolled my own SVG processing engine and it has addressed my needs. You can see the result on http://www.arosmagic.com/Solitaire. A simple breakdown is: Framework+CRT(150K), SVG engine(100k), SVG art(350k). My SVG library is sufficient for me for now. But I can't help wonder:1. Is there a better SVG library out there already available for easy inclusion?
2. If not, is there a need, i.e. market demand, for a lightweight (~200K) C++ SVG library that does not have the baggage of Silverlight or Flash?
If the answers are No/Yes, it may be worth it to make this library fully SVG compliant and release it as an open source alternative to the offerings from the entities that we shall not name but just collectively refer to as The Microbe. Please help out by letting me know if such a component is something that you would personally want to use in your current/future projects."
Inkscape? (Score:3, Insightful)
Re: (Score:3, Informative)
The Inkscape project is huge, but it almost sounds like you could rip livarot, Inkscape's current renderer, right from the code and use it. Inkscape itself doesn't even use Cairo because they consider it too immature (and, IMHO, it is, at this point).
OTOH, you could simply use librsvg to render the SVG graphics to PNG (or some other supported format) and display with the appropriate library calls.
Using librsvg this way always seemed like a bit of a kludge to me, but lots of projects use it for rendering.
So
Cairo too immature? (Score:4, Insightful)
OTOH, you could simply use librsvg to render the SVG graphics to PNG (or some other supported format) and display with the appropriate library calls.
You bash Cairo for being "too immature" (wtf, really? It's one of the most advanced 2D vector libraries out there), and then recommend a rendering library that is written exclusively to render to Cairo. Well played sir.
Re: (Score:1)
*I* didn't "bash" Cairo for being too immature, the Inkscape developers did. In their Wiki [inkscape.org]. I actually had no idea that librsvg used Cairo for rendering.
But I will say that I make heavy use of SVG and many advanced features, and when an application uses Cairo (like the Gnome Image Viewer) they never render correctly.
Re: (Score:2)
Are you out of your mind?
The overhead in Inkscape will surely be greater than the 2MB required for Cairo (which for some reason the OP finds unacceptable). Furthermore, Inkscape, like other similar applications, probably stores its graphics in an internal data structure. The SVG reading and writing are only a front-end for constructing and translating the internal data structure. The code that draws the image will be using the internal data structure, not actual SVG data. All of these things coupled togeth
Re: (Score:1)
Not looking at the code: +1.
Answer indicative of having RTFA: -10.
---
Net gain/loss: -9
Re: (Score:2)
Re: (Score:2)
Inkscape uses Cairo (Score:3, Informative)
Inkscape uses Cairo for all its rendering. Thus it is not going to be lighter weight than Cairo. There may be code in there that would provide a more useful interface, especially for C++ code. Reuse is always a good idea...
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Trim cairo? (Score:3, Interesting)
Re: (Score:1)
That's just a side effect of using David Bellot's SVG cards which only uses basic paint effects.
The intent is to be able to use all the fancy effects if they are present in an SVG file and supportable by the rendering hardware. Thus full SVG compliance is always a worthy goal, long term.
Re: (Score:2)
And I'm guessing that's without compression. Well, libbz2 is 70k and libz is 95k, so that might reduce the 2 megs by quite a bit, if he's concerned about download bandwidth.
If he's doing this for an embedded system, I imagine static linking would save him quite a bit.
Re: (Score:1)
Unfortunately, you got modded down, but you may have a valid point.
I did do a compile of Cairo under VS2005 with some significant wrestling. My 2M figure is from that. Perhaps I needed to have put more effort in it. Mind you my goal is to have a *total* package under 500K, that includes the artwork and the code.
As far as the C++ bindings go, in my library all I have are three functions:
1. Pass an SVG file name and Gdiplus::Graphics for bitmap rendering.
2. Ability to set/unset elements/properties in the DOM.
Webkit? (Score:3, Informative)
IÍ'd say QT/Webkit is the best bet currently. That will give you XML tools and a decent SVG view(er).
Re:Webkit? (Score:4, Interesting)
Pulling QtWebkit in is not exactly light weight. But Qt actually has another SVG rendered that implements the SVG tiny standard. Using QtSvg is still several megabytes of Qt libraries though, so except for the nice C++ interface, not the solution for the original question.
Re: (Score:2)
The fact is, vector art isn't cheap. Not computationally, not memory wise. Making a real go at it (not just faking a bunch of it, as many libraries do for speed) takes time, it takes work, it takes a bunch of libraries (XML parser, CSS parser, layout engine, etc). Putting any size constraint on it should at least take these things into account, which this developer quite clearly has not.
I'd s
Re: (Score:1)
...Cairo is an order of magnitude smaller.
And I want it an order of magnitude smaller still.
The fact is, vector art isn't cheap... (not just faking a bunch of it... it takes a bunch of libraries ...
Actually, I did do it cheap, I did fake it, and it didn't take a bunch of libraries (not counting OS). I'll admit that a compromise will probably need to be made for size reasons, though I'd rather leave them as compile time options. But most of those compromises have to do with outlying SVG features. A subject worthy of discussion when a full featured (or slightly less so) library is on the anvil.
I'd suggest he do his homework and look into the libraries that currently exist.
Believe me, I did do the homework. It may have been inadequa
Re: (Score:2)
Really? Why not? I would have thought it's just Bresenham and a bunch of other familiar algorithms (splines, clipping, antialiasing and stuff) into a raster buffer. ("Cheap" is relative. I'm thinking "cheap" as in "insignificant load on a computer from this millenium"; I remember that my Amiga 500 wasn't all that good for rendering Postscript.) We're talking 2D, non-animated, right?
Re: (Score:1)
In the process of developing the library, I built an SVG viewer to test it. The nice thing about having a GDI+ based SVG viewer is that it becomes trival to generate EMF+ files using it. Something that I can't do with any SVG renderer out there.
Also, having restricted myself to Windows, I was able to leverage MSXML. Though I am seriously pondering using tinyxml or some such library.
With that aside, QT has it's share of issues. It's not completely free and it has a heavy file size footprint, at least on Wind
Re: (Score:2)
Webkit is not the best bet for anything SVG related, its SVG support is absolutely horrid, as is Gecko's. It works for primative shapes, but move anywhere beyond that and they both failure to be useful. Scripting in webkit? Have fun. Filters? Yea right. Text alignment, whats that? If you want nothing more than to draw single color polygons, maybe with some borders you'll probably be okay, but even going so far as to add rounded corners to a rectangle and you've already ventured off of what Webkit can
Re: (Score:1)
The primary reason for using SVG is that it is an open, patent-free standard for which many free tools exist. This means original artwork is easy to author, archive and manage if it is SVG.
Even if I were to use a native vector library, I am still stuck with the need to use a file format. I tried to roll my own, but found that a lot of good work had already been done in SVG. It was almost a no-brainer to use SVG in hindsight.
"The non-open and proprietary..." blah blah (Score:4, Insightful)
That's just ideological drivel. The point is, SVG is a " standard " with a nice w3c.org - hosted spec and a nice diversified, academy-industry panel of contributors, but the fact remains, that in the 10 years since it became a standard, nobody really cares. Even browsers that support it officially only support subsets of it. The pragmatic reality is that it's a standard only in name, not in fact. If you want something with a clean, complete, consistent documentation describing a real, working, complete, multi-platform implementation, then what you call " proprietary" solutions are actually the way to go. Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.
blah blah, I don't know what I am saying blah blah (Score:5, Interesting)
The pragmatic reality is that SVG is becoming standard very quickly. Have a look at wikipedia.org. (Have you heard of it?)
" proprietary" solutions are actually the way to go. Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.
Yes, I'm sure that Adobe will have no problem with him using their library in his program that he gives out to all his friends and clients.
Re:blah blah, I don't know what I am saying blah b (Score:2, Interesting)
Yes, I'm sure that Adobe will have no problem with him using their library in his program that he gives out to all his friends and clients.
The Flash player? Go right ahead: "Adobe provides a free license to allow you to redistribute Adobe Flash Player or Adobe Shockwave Player on your company's intranet, or with your software product or service." (here) [adobe.com]
Ditto the XAML solution: the render is included in .NET 3.
The pragmatic reality, to borrow your phrase, is that more people have a Flash player installed than an SVG renderer.
Re: (Score:3, Insightful)
Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.
Maybe not but I'd argue it's a tad naive. Out here in the real world, there's nothing stopping a for-profit company from changing terms on their proprietary format license. After all, it's theirs. If they can make a profit by altering the terms in the future then why shouldn't they?
And proprietary formats work surprisingly well. Witness .doc as well
Re: (Score:2)
Re: (Score:3, Funny)
Yeah, I guess the OP would just have to convert his C++ project over to Java which is pretty much trivial! (since they both use C-based syntax)
Re: (Score:2)
Re: (Score:1)
A minor correction. The 2MB issue was for file size. Rendering vector graphics can be very RAM intensive. I have posted my thoughts on this in a separate place. Sorry about the confusion.
To remain in context, I'm hoping to do for C/C++ what Batik has done for JVM. Or at least a usable approximation of such. In a very light package. Or be pointed to the same if someone else has already done that work.
Re:"The non-open and proprietary..." blah blah (Score:4, Insightful)
...Even browsers that support it officially only support subsets of it.
Exactly. The root cause is that "lightweight" and "SVG" are mutually exclusive. SVG is an incredibly complex standard, and implementing it to spec is going to take incredibly complex code.
Re: (Score:1)
You may be right, but...
Having implemented a subset of SVG I found that most of the hard parts were in the absence of certain functions/functionality in GDI+. But I never felt that they can't be made whole with focused effort. It might require better brains than mine, and it might take a whole year. But it's doable.
As long as you are clear and focused about the objectives -- render {static,dynamic} SVG on {GDI+,OpenGL, Quartz, etc}. The key is to be focused.
Re: (Score:2)
You've never tried implementing a w3c spec I think. HELLOOOOO SWISS CHEEZE!
Re: (Score:1)
It's as easy as 1-2-3 to use the many variety of bitmap formats because there is either built-in OS support for them or good focused free open source libraries out there.
It has not been so for vector art. I just can't do a Draw(VectorFile, HDC/Gdiplus::Graphics), though I can do so for bitmaps. EMF+ gives you that functionality, but is non-portable and non-editable.
GDI+ implements so many SVG contructs close to spec it's scary. It's almost as if XAML was designed to spite SVG. That "intent" is so clear to m
I've been thinking... (Score:5, Interesting)
..about ripping the V8 and Skia engines from Chrome and making a standalone vector graphics system. Skia is light by design. V8 is fast and easy to embed by design. It's all C++ from the ground up. Implement the SVG interpreter in Javascript. Provide a JSON based alternative for the XML haters. Merge ongoing improvements from Chrome et al.
Just need a year of funding...
Re: (Score:2)
And in six days of waitting for your javascript to render a single flowRegion or text element, you might get to see the first letter. SVG via javascript would be absolutely painfully slow and worthless for anything of value.
Huh? (Score:1, Troll)
minimal system requirements
2. Flash/SWG, 3. Silverlight/XAML
Does not compute.
TWO WHOLE MEGABYTES? (Score:5, Funny)
2 megabytes of overhead? It ain't 1988 anymore, 2MB barely even registers these days.
I get the whole Slashdot obsession with bloat, but there's a limit.
Re: (Score:1, Troll)
It is ideology like that that give us bloatware and forces us to upgrade our hardware so we are able to run your program(s), assuming we want or need to, alongside others uninhibited.
Re: (Score:2)
It is ideology like that that give us bloatware
No, actually it's not. Saying that 2 megs is a trivial overhead is not the same as saying you should accept 500 meg programs that require dual core machines and gigs of memory. They aren't even in the same league.
and forces us to upgrade our hardware so we are able to run your program(s), assuming we want or need to, alongside others uninhibited.
If you have to upgrade your hardware to account for a 2 meg overhead in a program, you should consider upgrading to technology at least from the late 90s.
Re: (Score:3, Insightful)
But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.
Re: (Score:2)
It's all fine and dandy to write code that runs in a terminal and lets you play solitare in codepage 437 graphics, but this is 2009 and people expect more from their thousand dollar computers, and application developers like to have their software scale seamlessly to devices like phones, PDAs, Netbooks, etc.
Re: (Score:2)
Actually very early solitarie games certainly *did* have resolution-independent graphics. A few vectors to describe a card image took less space than a bitmap (granted the card images were usually a rectangle with a suit symbol and number). Vectors could easily be scaled to different sizes.
Re: (Score:2)
But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.
Let me try to care.... nope, can't do it. I'd rather have a solitaire that did something new and exciting in 20MB than the 4k compo. I don't think even my phone cares about 650kb vs 2mb anymore. On an odd coincidence, I just remembered making a card game in Java as one of my first exercises, lol. Never stayed with that language though.
Re: (Score:1)
The core logic of the game is less than 300 lines. Most of the space is the graphics or its support.
One motivation for doing vector graphics is reducing the file size for large displays apart from modeling convenience. In addition to that I am seeking a smaller file size for the executable that renders the vector graphics. Hence the original askslashdot.
Re: (Score:2)
I am actually impressed that you got your solitaire in 650K or so since it does so much. My version was on a Casio graphing calculator.
I get annoyed when people do not consider: what does my software do, what is reasonable in time and space
Many people decide as long as it is always below some arbitrary number, that is good enough.
They fail to realize that DRAM is not the only resource nor that they share it with all other processes. In particular a much more limited shared resource is the L1 cache. When sof
Handheld? (Score:2)
If you have to upgrade your hardware to account for a 2 meg overhead in a program, you should consider upgrading to technology at least from the late 90s.
A lot of handheld platforms still in use have capabilities comparable to that of technology from the mid-1990s. For example, Nintendo DS has 4 MB of RAM and similar GPU throughput to the original PlayStation and N64.
Re: (Score:1)
This is 2MB on disk that we're talking about here. That's the second most useless metric for a library I can imagine. Maybe I should choose my libraries based on how many lines of source went into them?
But don't let facts get in the way of your attitude.
Re: (Score:2)
Re:TWO WHOLE MEGABYTES? (Score:5, Informative)
Yeah, 2 whole megabytes may be too much. Remember there are *vastly* more small/dumb computing devices out there than the big-old desktop PC. So, maybe he's programming on a phone platform or some such and making a sincere effort to make something different.
I don't quite know what you are after, but I'll throw out SDL as a platform and SDL_svg. It may not fit in the requirements, but hey, it's worth a look.
Re: (Score:2)
Re: (Score:1)
You are probably right. But through conditional compilation, an open source library will give you that ability. The trouble comes in when you have a general purpose agent (like a browser) which must support the full spec. If all the SVG creatives are in your control, you can specify restrictions at source and achieve optimal file size/good-looks tradeoff.
I was unsuccessful in that attempt with Cairo, but I'll admit I may have given up too easy after about a week's worth of effort.
Re: (Score:2)
Good thought, but the summary specifically says he's coding Windows C++ programs. In which case, 2MB is such a drop in the bucket it doesn't matter.
Re: (Score:2)
Even phones have plenty of RAM. What they lack is CPU power, so any sort of acceleration he can take advantage of will help.
And acceleration usually means even more memory usage. :P
Re: (Score:2)
You assume that, but 2MB is a huge chunk if you're coding for say, Windows Mobile. Until WinMo 7 comes out, every application in WinMo is limited to 32MB total. That is code, stack, heap, and associated DLL's required, memory-mapped files, etc.
So even if your WinMo phone has 128MB of RAM, each application's memory area is only 32
Re: (Score:2)
Well, he freed up a whole megabyte and a half.
If memory usage is that tight, then I congratulate you for saving roughly 4.7% of the available memory.
Re: (Score:2)
Yeah, 2 whole megabytes may be too much. Remember there are *vastly* more small/dumb computing devices out there than the big-old desktop PC. So, maybe he's programming on a phone platform or some such and making a sincere effort to make something different.
Except we know he's not programming for something other than a "big-old desktop PC" because the title of the post is "Lightweight C++ Library for SVG On Windows?" Even for the crappiest/oldest Windows systems still in use, 2 MB is comically small. I I actually thought that spec was some sort of typo, but I guess not!
Re: (Score:2)
From http://www.libsdl.org/ [libsdl.org] :
SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
You just might have overreacted slightly.
There is Windows CE, you know (Score:2)
The story mentions WINDOWS
Perhaps the game for Windows is merely a prototype of something eventually intended to run on Windows Mobile or the like.
Re: (Score:1)
Dial-up is still around (Score:2)
2 megabytes of overhead? It ain't 1988 anymore, 2MB barely even registers these days.
A lot of people outside metropolitan areas still can't get an Internet connection faster than 0.05 Mbps.
Re: (Score:2)
Satellite, anyone?
Yes, some people are on the wrong side of a mountain, but I am guessing the number is significantly smaller.
Re: (Score:2)
As an aside I had to code for an embedded system with 4MB DRAM and 1MB FLASH where about half of the FLASH was already consumed by the loader, test, and config code from the vendor. I actually tried to put a portion of the code on the FLASH but there was a penalty of 4us per word on each access since it was on an IO bus and the FLASH was really slow. In the end I used 2MB of off board SRAM (battery backed and cksum verified on boot) and that had a penalty of only 1us per access. I get very annoyed when peop
Other Formats (Score:2)
While on the subject, I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).
XML isn't the only DOM serialization (Score:2)
I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).
There are representations of an element tree other than XML; one of them is called JSON. You could represent the SVG DOM in one of those, and then you could gzip it for further savings. And then use JavaScript to manipulate the DOM.
Re: (Score:2)
Problem is, by the time you make JSON a 1:1 mapping of the XML, you lose some of the advantages of JSON, I would think.
Or does SVG always use elements, instead of attributes?
Either way, a new standard would probably help in other ways.
Re: (Score:2)
Most modern Windowing systems are heavily influenced by these as well; Cairo is essentially DisplayPDF (using slightly different compositing operators; closer to the original Porter-Duff ones), Quartz even
Re: (Score:1)
I had that same dilemma going in since I dislike the verbose XML syntax. I hope my experience is of some help.
One of the ideas I had early on was, after reading in the SVG in memory, to save it back in a different "superior" file format to save space. The intent was to read this easier format and render it with no XML overhead. Turns out there was little gain, if any. SVG is fairly lean, as is, after compression. All the repetitive elements get compressed away to nothing by arithmetic compression.
The XML pr
Mobile SVG (Score:2, Interesting)
Antigrain rules (Score:5, Informative)
The author of Antigrain is a perfectionist.
Just look here - http://www.antigrain.com/svg/index.html [antigrain.com] . And version 2.4 is under BSD license.
Re: (Score:3, Interesting)
How would you say AGG [antigrain.com] compares to Cairo [cairographics.org]?
Re:Antigrain rules (Score:5, Informative)
Cairo has multiple backends: Pixman which is software, X11 (through XCB or XLib), Windows, Mac OS X, BeOS, PDF/PS/SVG, DirectFB, SDL, OS/2, several OpenGL backends (Glitz though it's unmaintained, and at least two 'plain' OpenGL backends from different hackers), an OpenVG backend and an in-progress DRI2 backend (which directly uses the graphics hardware in Linux). In addition, it has very rich font support, supporting the default font system on the platforms above, and includes support for user-defined fonts. AGG's font support is rather mediocre, supporting only Freetype and Win32. Neither library does much extensive layout code, though Pango uses Cairo to produce (arguably) the best text layout experience in the (FOSS) world.
AGG has a richer set of vector-related features, such as Gaussian filtering (which has been a todo item for Cairo for quite some time), Type-6/7 meshes with Gouraud shading and image warping, and provides Gamma correction. Some work has been done on adding Gamma and color correction to Cairo, but I don't believe there's anything deliverable at this point.
Cairo has a richer set of bindings; being written in C, it has bindings to practically every commonly used programming language, and a few uncommonly/rarely used ones, such as OCaml and Keith Packard's Nickel language.
All-in-all, it's about what you're going to do with the two libraries. AGG is written more towards a graphics package, like Inkscape or the GIMP. Cairo is written more to be the backend of a display system, like Quartz2D.
Re: (Score:1)
I looked at AGG brief. No doubt a work of a person more qualified and talented than yours truly. He has even implemented an SVG renderer.
Unfortunately, it suffers from three problems:
1. Even though the AGG renderer is superior visually to GDI+, it is extra baggage in file size and the visual differences not great enough to justify that difference.
2. Inability to use hardware acceleration that GDI+ gives.
3. The SVG processor is woefully inadequate, even less than my humble efforts. It really only highlight A
Re: (Score:2)
GDI+ does not use hardware acceleration, and AGG is actually faster ;)
Re: (Score:2)
Re: (Score:2)
Yes, you are correct. However, GDI is capable of accelerating only very basic operations (flood fill, bitblits). It can't accelerate antialiased line drawing and gradient fills.
And it's quite ironic, because internally GDI+ has a lot of hooks for hardware acceleration. Only no one has ever implemented it.
What about CGM aka ISO 8632:1992 (Score:1, Informative)
CGM exists since about 1985, is standardized by ISO and supported by many applications (Corel, AI, Freehand,...). Binary and ascii representations exist.
Might be worth a look.
SDL_svg (Score:1)
LibBoard? (Score:2)
http://libboard.sourceforge.net/ [sourceforge.net]
Juce (Score:1, Informative)
Im surprised no one has mentioned the Juce library. It has svg support for multiple platforms.
http://www.rawmaterialsoftware.com/juce/index.php
Re: (Score:1)
Thanks. Hearing about it for the first time. It looks like a solid piece of work. However (ignoring GPL for the moment), it says it has an "Importer for simple SVG files...", implying it probably only has a fraction of SVG.
It's demo programs are also coming in at ~650-900K. It might be too heavy. Perhaps if there was just a demo of an SVG viewer a proper evaluation can be done...
C#.NET vector graphics library? (Score:2)
At the risk of offending the geek-gods, would anyone be able to answer the same question, but for C#/.NET? Everything I've found so far for rendering SVG written in C# is either "under development" or "abandoned".
Re: (Score:2)
If you're playing in Windows C#Net, you really want to take a look at WPF. Microsoft basically "embraced" the SVG spec into the System.Windows.Media objects, and "extended" the objects to mesh with the rest of the architecture, and wrapped it all with binding properties so it can do some pretty interesting stuff. http://msdn.microsoft.com/en-us/library/ms742562.aspx [microsoft.com]
Re: (Score:1)
Probably because Silverlight/XAML is the correct answer if you are doing any .Net work. Just a no brainer if you are an ISV. SVG start looking superfluous.
It is also fairly easy to take an unmanaged C++ SVG engine and put CLR bindings for it. But a world of pain vice versa.
Silverlight is an obvious long term strategy to extinguish SVG and supplant it with XAML. Same as they did to OpenGL with DirectX. Or tried to.
The 2M requirement (Score:1)
Some of you have responded negatively to the need of rejecting a library with >2M overhead. Allow me to address that instead of responding individually.
Regrettably, I was unclear about what that 2M referred to. I totally meant the file size, not the memory footprint. The real utility of vector graphics shows up on large displays, meaning large buffers in the 5-30M RAM range, so imposing a RAM limitation is not wise per se.
The reasons for wanting a small file size are threefold:
1. Lower bandwidth cost
2. B
Re: (Score:2)
I'm all in favor of having a small linkable SVG library! I've been looking for something like that for a while, but haven't found anything acceptable for my needs. So instead of displaying the SVG's directly I prerender to PNG and show that instead. That makes the icons the only part of the user interface that don't scale.
I've considered ripping the rendering engine out of Inkscape and building a standalone library out of that. Problem is, it is a lot of work for a cosmetic gain...
OpenVG (Score:1, Informative)
http://www.khronos.org/openvg/
My SVG Library (Score:2, Interesting)
I've been working on a similar problem in my spare time for quite some time now. I needed a SVG library that was BSD-compatible, could draw any Adobe Illustrator SVG, and selectively enable or disable objects by their ID that was suitable for inclusion in a 3D game.
I couldn't find any library that fit the requirements, so I ended up writing a C++ library called Donner SVG. It is heavily based on librsvg except written with SVG DOM in mind and for minimal dependencies. It's only dependencies are Cairo, ra
For Windows, use GDI+ as a basis? (Score:2)
I would think that if you are looking at C++ in Windows that you would probably consider using GDI+ as the basis for an SVG style render. GDI+ fits in nicely with Windows DC model, but is very cleanly object oriented.
And um, I would think that, by its nature, SVG is not going to be all that small....
Re: (Score:2, Informative)
Re: (Score:2)
I have to ask. . . the MAP (Main Article Poster) was asking for a *lightweight* SVG implementation. If he uses Qt, won't he have to load the *entire* Qt library, including all the code for all the different windows and widgets and data structures he's not interested in? How modular is Qt? I suppose if they've broken it down into enough libraries, maybe the set of libs he would need to load might not be bad. . .
Re: (Score:2)
Qt is a good choice. Qt includes stuff he's probably going to have to include anyway, like strings, collections, GUI, networking, XML, etc. Just dump the MFC or .NET that he's already using and switch to Qt.
Qt is already modules. For using SVG you need core, gui and xml modules. No need for network, sql, phonon, webkit, etc. But if that's not small enough, you can configure away a lot of classes (a standard procedure for embedded).
Qt runs on cellphones, so there's no excuses that it's too big for a Windows
Re: (Score:1)
Qt is a good choice... .. like strings, collections, GUI, networking, XML, etc... Just dump the MFC or .NET ...
Considering that Qt is not really totally free, not a good choice. Plus it's fat is worse than native Windows when you factor in static compilation. .NET, no MFC. And I daresay the standard C++ library plus Win32 is good enough. Even GDI+ was a reluctant addition, but I succumbed to using it since most Windows installation have it by default. Ditto for MSXML.
If you would have given my program a spin you might have noticed my disdain for unnecessary fat. Hence no
Re: (Score:2)
Qt is lpgl and gpl. What more do you want?
Re: (Score:2)
Qt is broken into many modules. However, I'd still be surprised if you managed to make Qt use muc
Re: (Score:2)
However, I have to defend FOSS software on a closed operating system. It's perfectly feasible, just as running proprietary software on a FOSS operating system. The two simply don't exclude the other.
Re: (Score:1)
For the ad-ness of the posting, I apologize. Though I don't know how to demonstrate the utility of a library without showing it working in a real live app.
My primary intent is to be able to use SVG within my programs. If the OS (proprietary or not) had that built-in I would have been happy. In order to do get that functionality, I wrote a library. It works, but is incomplete. If a product already exists, I'd much prefer that (and Cairo is a fine product, just heavy).
If such a product does not exist, I would
Re: (Score:2)
RTFS, wow.