Slashdot Mirror
Lightweight C++ Library For SVG On Windows?
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."
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."
I haven't looked at the code, but is there something that you can leverage from Inkscape?
It's a simple matter of complex programming.
It looks like your needs/game only use basic vectors, nothing fancy like blends, blurs. Could you just strip out much of the code from the SVG source that does stuff you don't foresee using?
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
IÍ'd say QT/Webkit is the best bet currently. That will give you XML tools and a decent SVG view(er).
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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.
..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...
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.
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.
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).
Please correct me if I got my facts wrong.
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 as AutoDesk's venerable .dwg format. A truly obfuscated mess and they're still number one because of it.
I'd suggest looking at projects for bringing SVG to smartphones. You may find an SVG library for Windows CE that would compile under (vanilla) Windows -- probably not feature complete, but chances are the Mobile SVG specs are enough for your needs. I believe there is at least one very trim branch of Firefox underway, though SVG support may be one of the things that it trimmed. Good luck.
Like SDL_svg? http://www.linuxmotors.com/SDL_svg/
We're using Batik and it's great. It's real, working, (mostly) complete, and multi-platform. Does it cover absolutely everything? No, it doesn't (see their status page), but it has done everything that we want it to do.
The more people I meet, the better I like my dog.
The author of Antigrain is a perfectionist.
Just look here - http://www.antigrain.com/svg/index.html . And version 2.4 is under BSD license.
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. . .
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)
That was the turning point of my life--I went from negative zero to positive zero.
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.
works for me. http://sdlsvg.sourceforge.net/
And of course, while he's worried about Cairo eating 2 MB of RAM, I'm sure the massive amount of RAM consumed by the JVM won't bother him in the least...
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
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.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
From http://www.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.
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.
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.
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.
http://libboard.sourceforge.net/
...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.
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...
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Yeah, it does read a bit like a disguised product announcement.
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.
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)
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.
RTFS, wow.
Don't thank God, thank a doctor!
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 desktop.
Don't blame me, I didn't vote for either of them!
Im surprised no one has mentioned the Juce library. It has svg support for multiple platforms.
http://www.rawmaterialsoftware.com/juce/index.php
Qt is broken into many modules. However, I'd still be surprised if you managed to make Qt use much less than 2MB of RAM with less work than it took for the MAP to write his custom engine. I'm still deeply confused about why 2 MB is such a concern on a desktop app. Is the MAP targeting Win95 systems with 8 MB of RAM? On any system capable of running a currently shipping version of Windows, 2MB of RAM is much smaller than anything worth investing a lot of time over. The only real issue I can see would be in Internet distribution for an app targeting people using dialup connections. On dialup, 2MB would add a significant amount of time to the transfer.
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".
You've never tried implementing a w3c spec I think. HELLOOOOO SWISS CHEEZE!
http://xkcd.com/386/
"In the absence of the ability to establish the attribute of truth they tried to establish the noble attributes."
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 like to know if someone else desires it; because making it fully SVG compliant is a lot of work and is only worth doing if someone will actually use it.
Much as I would like to make billions from my labour, I'm realistic enough to recognize that a free superior Cairo is not worth competing against, hence if my library has to be published it must be free and open.
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. Better NUMA optimization
3. Smaller surface area for bugs
1. Bandwidth: As an online publisher, you have to pay for every byte that is served over the wire to the customers. It's a minuscule cost when there are only a thousand downloads. But if you ever dream of millions or more of downloads, the cost of that adds up rapidly. That's when a library that is only 200K is better than a 2M one.
2. Faster Memory performance: Given the NUMA nature of modern computers, you get better performance the higher up in the hierarchy you are. Hence, there is a greater chance of your program's working set sitting in the L1 cache if it is small.
3. Bugs: This is probably doesn't need much explaining, since smaller programs are easier to make bug free.
I think there are four major inflection points today as far as file size for programs is concerned:
size < 100K
100K <= size < 5M
5M <= size < 50M
size >= 50M
Without a doubt Cairo is appropriate for the latter two, i.e. if your project is >=5M in size.
But if your SVG artwork+code is already <1M, it makes no sense to add >2M code overhead when a 200K library can do the job. I think a lot of software is (or should be) in that category. The only reason it isn't so is because everybody is using bitmaps that up the file size when vector art is more appropriate. They do that because there is no easy native OS support.
Now someone possibly more knowledgeable than I mentioned here that Cairo's footprint might actually be smaller (maybe 1M) if you tweak with it enough, so it might be worth taking a second look at. But I hope my thoughts will convince you that pursuing a smaller binary size is a worthy endeavour, especially in a library.
http://www.khronos.org/openvg/
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 me now that I have implemented a GDI+ based SVG renderer that I can't help marvel that someone like you would willingly drink the Microbe cool-aid. Unless you are their agent, of course. As I once was, in another life time.
No it is quite clear that The Microbe strategy is to Embrace, Extend and Extinguish and they will do (or not do) anything in their power to extend their defacto cartel on the graphics market.
Even if SVG, and my minor inconsequential efforts at building a rendering library for it are just a thorn at the side of the evil empire, I'm just happy to do my bit in twisting it in.
Unless, of course, they are willing to pay me billions to quit. In which case I'll refer to them as a Symbiote. But I don't think they are willing to do the name change just yet
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.
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.
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
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, rapidxml, and libcroco, but none of libcroco's dependencies as I wrote a compatibility layer. Additionally, the renderer can be easily swapped out to eliminate the Cairo requirement.
Some notable features:
- Ability to access the SVG document tree and modify it after loading an SVG.
- Supports all shapes and paint server types (radial and linear gradients with stops, solid colors, and transparency).
- CSS2 selector support.
- Bounding box calculation.
It renders static SVGs very well, but I don't consider it to be releasable yet. My goal is to fully implement the #SVG-static feature string and use the library to implement a SVG extension for skeletal animation and inverse kinematics.
I'm willing to send a copy of the source over if anyone is interested, just contact me at "donner (at) jeffrules (dot) com". It is licensed under the LGPL as parts of it are borrowed from librsvg.
- - - - - - -
Orppf urp mf y.ppcxn. yflcbi otcnnov C am yflcbi yr n.apb Ekrpatv (Dvorak -> Qwerty)
Qt is lpgl and gpl. What more do you want?
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....
This is my sig.
Last time I had checked (couple of years ago) I got the impression it was GPL or commercial. Now I see that the former has been changed to LGPL. I stand corrected.