Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Lightweight C++ Library For SVG On Windows?

timothy posted more than 5 years ago | from the put-a-choke-on-your-tla-dectector dept.

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

Sorry! There are no comments related to the filter you selected.

fp (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28127813)

props to all dead homiez

story needs an "ad" tag (0)

Anonymous Coward | more than 5 years ago | (#28129473)

How neat, an Ask Slashdot post, but when you go into it you find that it's really a product announcement disguised as a question. (With a few FOSS-related platitudes throw in to seal the deal.)

So let me get this straight: This guy has Windows C++ programs he's written, and he desperately wants to find an open, non-proprietary library to enhance his programs that run on a closed, proprietary OS? Oh I only want to add sugar-free sweetener to my non-diet cola because I'm trying to cut back on sugar!

Re:story needs an "ad" tag (1)

Toonol (1057698) | more than 5 years ago | (#28131415)

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.

Re:story needs an "ad" tag (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28134761)

Writing software for a closed, proprietary OS promotes its ecosystem over that of an open, non-proprietary OS.

The submitter who got his pet project on the Slashdot front page included language implying he's "one of us". But he's contributing to an "evil" software empire, so his Slash-speak is just verbal whoring to get placement here.

Re:story needs an "ad" tag (1)

redblue (943665) | more than 5 years ago | (#28134857)

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.

Inkscape? (2, Insightful)

PinkPanther (42194) | more than 5 years ago | (#28127861)

I haven't looked at the code, but is there something that you can leverage from Inkscape [inkscape.org] ?

Re:Inkscape? (3, Informative)

morgan_greywolf (835522) | more than 5 years ago | (#28128673)

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, to answer the OPs question as to whether or not there is a need for a lightweight C/C++ renderer -- I'd say yes.

Cairo too immature? (3, Insightful)

ciroknight (601098) | more than 5 years ago | (#28130411)

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:Cairo too immature? (1)

morgan_greywolf (835522) | more than 5 years ago | (#28133209)

*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:Inkscape? (1)

SupplyMission (1005737) | more than 5 years ago | (#28128813)

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 together will almost certainly result in a multi-megabyte overhead.

Furthermore, in addition to the multi-megabyte overhead, but there will be the [probably not insignificant] time and effort required to learn the Inkscape architecture. Then he will need to find and extract the relevant parts of code, so that they can be linked to his C++ program.

In short, I'm afraid that "leveraging" Inkscape is not a very feasible idea at all.

Re:Inkscape? (0)

Anonymous Coward | more than 5 years ago | (#28129055)

Inkscape is a good editor, but you will probably spend a lot of time trying to figure out a way to get the library out of the program. It sounds to me like redblue recreated parts of librsvg, which may be the free lightweight library he is looking for. As an aside, I think if openoffice had a plugin using librsvg (or some other well-maintained svg library) to render (even complex) svg files so they look right, svg adoption would go much faster.

Re:Inkscape? (1)

salarelv (1314017) | more than 5 years ago | (#28135567)

They are developing a version which is based on cairo.

Re:Inkscape? (1)

goldaryn (834427) | more than 5 years ago | (#28129129)

> I haven't looked at the code, but is there something that you can leverage from Inkscape?

Not looking at the code: +1.
Answer indicative of having RTFA: -10.
---
Net gain/loss: -9

Re:Inkscape? (1)

PinkPanther (42194) | more than 5 years ago | (#28130415)

This AskSlashdot was about "SVG C++ code for Windows". What is it you claim I missed?

Re:Inkscape? (1)

fractoid (1076465) | more than 5 years ago | (#28134341)

He was shooting for teh funnay. You're not conforming to the slashdot stereotype of "I didn't RTFA" but he gave you a bonus point for not reading the code. I presume you could have scored additional points by saying that Natalie Portman accidentally a word while running Linux is like a car made out of hot grits.

Inkscape uses Cairo (2, Informative)

Giant Electronic Bra (1229876) | more than 5 years ago | (#28131349)

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:Inkscape? (1)

drakaan (688386) | more than 5 years ago | (#28134683)

If I recall correctly, Firefox can display SVG...maybe a talk with Mozilla devs is in order?

Trim cairo? (2, Interesting)

EkriirkE (1075937) | more than 5 years ago | (#28127887)

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?

Re:Trim cairo? (0)

Anonymous Coward | more than 5 years ago | (#28129403)

He said "AFAIK", which apparently he doesn't. Cairo &+ C++ bindings, with liberal options, are under a meg. That gets you some font support, PDF, and lots of things that are optional. I don't know if it would come down to 200k, but I wouldn't be surprised if it did.

While I'm at it, the bindings aren't any more obscure than anything else written in C++.

Re:Trim cairo? (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28131699)

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:Trim cairo? (1)

redblue (943665) | more than 5 years ago | (#28135271)

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.
3. Acquire the bounding rectangle of a rendered sub-element.

Maybe it's easy and straightforward in Cairo -- it just wasn't so when I had looked at it. My bad. If you could point to a working example, it would be greatly appreciated. I would much rather use a working superior product than roll my own.

Re:Trim cairo? (1)

redblue (943665) | more than 5 years ago | (#28135185)

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.

Webkit? (2, Informative)

EsbenMoseHansen (731150) | more than 5 years ago | (#28127915)

IÍ'd say QT/Webkit is the best bet currently. That will give you XML tools and a decent SVG view(er).

Re:Webkit? (0)

Anonymous Coward | more than 5 years ago | (#28128181)

If he doesn't want 2MB of Cairo, why would >2MB Webkit?

Re:Webkit? (3, Interesting)

Carewolf (581105) | more than 5 years ago | (#28128361)

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:Webkit? (1)

ciroknight (601098) | more than 5 years ago | (#28130493)

QT/Webkit once you've got all of the dependencies down is over 20 megs. Cairo is an order of magnitude smaller.

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 suggest he do his homework and look into the libraries that currently exist.

Re:Webkit? (1)

redblue (943665) | more than 5 years ago | (#28135367)

...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 inadequate, but it would be more helpful if you could specifically point out where. All I wanted were the following functionalities:
Draw(Gdiplus::Graphics, SVGFileName)
Set/GetProperty
BoundingRectangle

Just didn't get it in a nice free 200K package in Cairo, libart, AGG, eSVG, etc.. Perhaps if you could point me to a working example/demonstration I'd be more than grateful.

Re:Webkit? (0)

Anonymous Coward | more than 5 years ago | (#28130981)

As a developer who uses SVG: Webkit isn't a very good SVG viewer. Depending on what I'm doing, I've found it's sometimes equal to, but often worse than, Gecko's SVG rendering. (I'd suggest Gecko, but it's not exactly small.)

If you're writing desktop software and don't specifically need SVG, but simply vector graphics, I'd use a native library like Cairo.

Re:Webkit? (1)

redblue (943665) | more than 5 years ago | (#28135395)

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.

Re:Webkit? (1)

redblue (943665) | more than 5 years ago | (#28135319)

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

"The non-open and proprietary..." blah blah (4, Insightful)

El Cabri (13930) | more than 5 years ago | (#28127935)

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.

No. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28128235)

You are wrong.

blah blah, I don't know what I am saying blah blah (4, Interesting)

Kludge (13653) | more than 5 years ago | (#28128309)

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 (2, Interesting)

Anonymous Conrad (600139) | more than 5 years ago | (#28131807)

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:"The non-open and proprietary..." blah blah (2, Insightful)

theskipper (461997) | more than 5 years ago | (#28128471)

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.

Re:"The non-open and proprietary..." blah blah (1)

Beezlebub33 (1220368) | more than 5 years ago | (#28128643)

We're using Batik [apache.org] 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.

Re:"The non-open and proprietary..." blah blah (2, Funny)

Billy the Mountain (225541) | more than 5 years ago | (#28129669)

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:"The non-open and proprietary..." blah blah (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28129821)

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

Re:"The non-open and proprietary..." blah blah (1)

redblue (943665) | more than 5 years ago | (#28135509)

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 (0)

Anonymous Coward | more than 5 years ago | (#28129119)

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.

For now.

But they may change them which they can do because they own them.

My Brother got stung badly developing for a 'community' game engine which was subsequently sold, and the new owner started charging to distribute the libraries.

If its open source your development can't be marooned like this.

Re:"The non-open and proprietary..." blah blah (3, Insightful)

eggnoglatte (1047660) | more than 5 years ago | (#28130695)

...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:"The non-open and proprietary..." blah blah (1)

redblue (943665) | more than 5 years ago | (#28135539)

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:"The non-open and proprietary..." blah blah (1)

Shados (741919) | more than 5 years ago | (#28134283)

The point is, SVG is a " standard " with a nice w3c.org

You've never tried implementing a w3c spec I think. HELLOOOOO SWISS CHEEZE!

Re:"The non-open and proprietary..." blah blah (1)

redblue (943665) | more than 5 years ago | (#28135485)

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

I've been thinking... (5, Interesting)

Anonymous Coward | more than 5 years ago | (#28128093)

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

Huh? (0, Troll)

harryandthehenderson (1559721) | more than 5 years ago | (#28128169)

minimal system requirements

2. Flash/SWG, 3. Silverlight/XAML

Does not compute.

TWO WHOLE MEGABYTES? (5, Funny)

The End Of Days (1243248) | more than 5 years ago | (#28128205)

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:TWO WHOLE MEGABYTES? (0, Troll)

EkriirkE (1075937) | more than 5 years ago | (#28128369)

I sure hope you are not a developer or never plan to be one.

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:TWO WHOLE MEGABYTES? (1)

harryandthehenderson (1559721) | more than 5 years ago | (#28129069)

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:TWO WHOLE MEGABYTES? (2, Insightful)

mzs (595629) | more than 5 years ago | (#28130105)

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:TWO WHOLE MEGABYTES? (1)

ciroknight (601098) | more than 5 years ago | (#28132075)

You didn't have resolution-independent graphics, either.

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:TWO WHOLE MEGABYTES? (0)

Anonymous Coward | more than 5 years ago | (#28133131)

"this is 2009"

OS/2 had resolution independent solitaire back in the early nineties.

Re:TWO WHOLE MEGABYTES? (0)

Anonymous Coward | more than 5 years ago | (#28132085)

He's using SVG. If he were using strictly GDI+ I'd agree with you, but since he wants to use SVG, he should kiss the whole lightweight thing goodbye.

Re:TWO WHOLE MEGABYTES? (1)

Kjella (173770) | more than 5 years ago | (#28133437)

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.

Handheld? (1)

tepples (727027) | more than 5 years ago | (#28130395)

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:TWO WHOLE MEGABYTES? (1)

The End Of Days (1243248) | more than 5 years ago | (#28130081)

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:TWO WHOLE MEGABYTES? (1)

EkriirkE (1075937) | more than 5 years ago | (#28130809)

*whoosh*

Re:TWO WHOLE MEGABYTES? (4, Informative)

mpapet (761907) | more than 5 years ago | (#28128441)

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:TWO WHOLE MEGABYTES? (1)

Beezlebub33 (1220368) | more than 5 years ago | (#28128683)

SVG is pretty broad. There's lots of pieces, and so the library is going to be big. 2M of C++ holds a huge amount of functionality. So, I'd think that the choices are either to pick a subset of the functionality or take the 2M.

The story mentions WINDOWS, you braindead simp (0)

Anonymous Coward | more than 5 years ago | (#28129025)

RTFA. And wipe up that drool, you're not in high school any more.

Christ, Slashdotters just keep getting dumber.

Re:The story mentions WINDOWS, you braindead simp (1)

TopherC (412335) | more than 5 years ago | (#28130425)

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 (1)

tepples (727027) | more than 5 years ago | (#28130433)

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.

Yes and perhaps... (0)

Anonymous Coward | more than 5 years ago | (#28130585)

...it's going to run on a fucking 64-core monstrosity with 100 Petabytes of fucking RAM.

Or we could STOP READING OUR OWN ASSUMPTIONS INTO THE FUCKING SUMMARY.

How about we do that, huh?

Re:TWO WHOLE MEGABYTES? (1)

Blakey Rat (99501) | more than 5 years ago | (#28129419)

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:TWO WHOLE MEGABYTES? (1)

BikeHelmet (1437881) | more than 5 years ago | (#28130729)

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:TWO WHOLE MEGABYTES? (1)

tlhIngan (30335) | more than 5 years ago | (#28134489)

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

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 32MB in size. There are tricks you can do to allocate memory from another "slot", but each slot is, again, 32MB in size. If other apps did the same, you could run out, and your requests will fail.

This 32MB/process limit comes from Windows CE (of which Windows Mobile borrows its base) 5 and below. Windows CE 6, and Windows Mobile 7 use a more traditional memory model akin to a regular traditional OS (0-2GB user, 2+-4GB kernel memory model).

That 2MB of code could very well mean there's barely enough room to fit the rest of the app and its data in memory...

Re:TWO WHOLE MEGABYTES? (1)

BikeHelmet (1437881) | more than 5 years ago | (#28134943)

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:TWO WHOLE MEGABYTES? (1)

SwabTheDeck (1030520) | more than 5 years ago | (#28131007)

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!

Dial-up is still around (1)

tepples (727027) | more than 5 years ago | (#28130475)

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:Dial-up is still around (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28131945)

Satellite, anyone?

Yes, some people are on the wrong side of a mountain, but I am guessing the number is significantly smaller.

If you have the time/energy, then yes, please do. (0)

Anonymous Coward | more than 5 years ago | (#28128221)

But please make it work cross-platform through SDL and/or OpenGL or AGG.

If it is cross-platform, I could see there being some interest at least in the indie game development community.

Re:If you have the time/energy, then yes, please d (2, Informative)

erebus24 (632942) | more than 5 years ago | (#28128623)

Like SDL_svg? http://www.linuxmotors.com/SDL_svg/ [linuxmotors.com]

XAML is free. Quit spreading FUD. (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28128251)

http://en.wikipedia.org/wiki/Open_Specification_Promise

XAML is not a UI language or graphics format. It is an XML Based Application(Avalon) Markup Language.

What you want are xaml constructs made up of Paths and Glyphs. Inkscape will export these with minor bugs to be fixed in your favorite text editor (last i checked it was putting a "px" after a pixel width, ie Stroke="3px" instead of Stroke="3").

You can print anything you want to an XPS file (under vista), then extract that xps and get the xaml out (an xps is a xaml + resources zipped in a file)

Under windows (DX10+) your UI will be accelerated on the GPU. With any other alternative it's all software.

Or you can fuck around in vi or emacs like its 1984 and reinvent the wheel again because the wheels on the car are "too proprietary".

You could do a google search and find http://www.antigrain.com/, libsvg, and 100 other alternatives - but of course this article is only posted for ignoramus linux "users" to rail against the XAML "machine".

Other Formats (1)

RAMMS+EIN (578166) | more than 5 years ago | (#28128467)

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 (1)

tepples (727027) | more than 5 years ago | (#28130541)

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:XML isn't the only DOM serialization (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28132017)

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:XML isn't the only DOM serialization (0)

Anonymous Coward | more than 5 years ago | (#28134703)

Or does SVG always use elements, instead of attributes?

Yes. It is basically a fancy S-expression syntax, with support for some data structures. Not surprising -- JavaScript is a Lisp, after all.

Re:Other Formats (1)

ciroknight (601098) | more than 5 years ago | (#28132187)

PostScript, PDF are still the winners in terms of adoption and efficiency. PostScript is more burdensome code-wise, so most everyone today will recommend PDF (it's essentially "PS-lite") or even a subset of PDF (most commonly throwing out things like quadradic Bezier curves and higher-level filtering).

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 more so than Cairo (implements filtering operators, etc). Even Windows has gotten off the bitmap and uses a similar model for their display system in XP/Vista with GDI+.

Mobile SVG (2, Interesting)

SpaceToast (974230) | more than 5 years ago | (#28128527)

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.

Qt (0)

Anonymous Coward | more than 5 years ago | (#28128757)

try using Qt library. It has some SVG support. Although I am not sure how complete it is...

Re:Qt (1)

JSBiff (87824) | more than 5 years ago | (#28129187)

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:Qt (1)

Brandybuck (704397) | more than 5 years ago | (#28133027)

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.

Re:Qt (1)

forkazoo (138186) | more than 5 years ago | (#28133315)

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

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.

Improvements eh? (0)

Anonymous Coward | more than 5 years ago | (#28128769)

> Windows
> can you improve

Well...

Antigrain rules (4, Informative)

Cyberax (705495) | more than 5 years ago | (#28128939)

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:Antigrain rules (2, Interesting)

RAMMS+EIN (578166) | more than 5 years ago | (#28130653)

How would you say AGG [antigrain.com] compares to Cairo [cairographics.org] ?

Re:Antigrain rules (4, Informative)

ciroknight (601098) | more than 5 years ago | (#28132683)

Shortlist: AGG is a software renderer, and is a bit faster than Cairo-Pixman, though is less accurate than Cairo (Cairo is designed for correctness over performance, where possible, but does have an extensive regression and performance testing framework).

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.

Boost google SOC 2007 svg_plot (0)

Anonymous Coward | more than 5 years ago | (#28129091)

I've used this one, the svg_plot library in the boost sandbox, developed as part of the google summer of code 2007
http://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/libs/svg_plot/doc/pdf/svg_plot.pdf

Cairo Graphics Librar (0, Redundant)

doktaru (1527945) | more than 5 years ago | (#28129445)

You might want to look at Cairo. It has a Win32 backend as well as many other platforms. It is written in C and has bindings for C++ and lots of other languages as well. http://cairographics.org/ [cairographics.org]

Re:Cairo Graphics Librar (0)

Anonymous Coward | more than 5 years ago | (#28129543)

*whoosh!*

Re:Cairo Graphics Librar (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28132411)

RTFS, wow.

What about CGM aka ISO 8632:1992 (1, Informative)

Anonymous Coward | more than 5 years ago | (#28129679)

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.

Juce (1, Informative)

Anonymous Coward | more than 5 years ago | (#28133111)

Im surprised no one has mentioned the Juce library. It has svg support for multiple platforms.
http://www.rawmaterialsoftware.com/juce/index.php

C#.NET vector graphics library? (1)

Stiletto (12066) | more than 5 years ago | (#28133317)

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:C#.NET vector graphics library? (1)

Orne (144925) | more than 5 years ago | (#28133427)

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]

The 2M requirement (1)

redblue (943665) | more than 5 years ago | (#28135151)

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.

OpenVG (1, Informative)

Anonymous Coward | more than 5 years ago | (#28135463)

http://www.khronos.org/openvg/

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?