To combat the rising tide of surgically transplanted organs by alien terrorists what is needed is a... probe...for an organ they dare not change. Like the prostate area.
I would be loath to put a potentially malware infested software like G-WAN on my machines, so am unable to make a direct comparison. I also don't have a machine that matches the spec published for it. Nevertheless, the G-WAN curves are similar to rani's curves for TPS. Perhaps you could share the performance numbers that you have observed? As for the rest, it was a weekend effort. What more do you expect?
A while back I had written a minimal HTTP server to figure out I/O completion ports in Windows over a weekend. You can download it from (BSD license): http://arunsagar.com/Code/rani.cpp Similar throughput specs as the OP's server, and the C++ code can be part of the server itself (great for debugging). Buggy and incomplete, but you can play, fix and extend as you wish.
And I just finished reading Anathem. It's quite gripping and entertaining, far from being awful. It is an impressive effort at stitching together some of the leading philosophical and scientific issues of our time in a work of fiction. It is still a Neal Stephenson book -- meaning there is 3 pages of plodding drivel for every page of sheer brilliance. But he has improved from his Baroque cycle (>10:1 ratio). I think you gave up too early, i.e., the good stuff happens in the second half of the book. It also helps if you are going "WTF?" trying to make sense of the Arban vocabulary and mythos; that means the book is thought provoking and you will probably enjoy it as a result. I would hate to even give a hint as to how it progresses, but it is totally a hard sf book, about as hard as it can get without becoming non-fiction. It could have had more humor like his earlier work, but he probably ratcheted down given the nature of the story. Unlike his earlier books, even the ending doesn't suck, which is saying a lot. The best way to read this book is to imagine a puzzle's solution is being unfurled right before your eyes. You can guess what it will look like at the end, and may even solve it before the book is over; nevertheless it is the journey, the experience of reading the book, that makes it worthwhile. Or not, if you don't like long 1000 page journeys unless they are all adrenaline pumping every single page.
If you break down accessibility in to 3 essential components : 1. local loop, 2. back-haul, 3. international connectivity, you'll find that India has severe problems with 1&3 and not 2. You can get all the expertise for 2, but there is a de-facto cartel blocking cheap access to #3 and even if you were to solve that problem (through better negotiations or laying your own ocean fibre), I think the worst problem is #1. Even that suffers from a difficult problem: lack of demand. Of the people willing to pay for broadband, most will opt for the Rs.100-250/mo plan for crapband. Very few will see the value in the Rs.1000/2Mb+(uncapped) plan and they will not drive your market in volume. I think this is the reason that Reliance, Tata and Bharti have not expanded their ISP offerings beyond the top tier markets and they basically have no problems with #2 above (or even #1, which is a relatively minor marginal expense). Unfortunately and very regrettably, I think your venture is doomed, much like Indian Railways' railnet.
It's not as if they will incur the wrath of Xenu if Bender joins an adventure club. Personally, I would like to see some more changes. Too many dysfunctional Euro-Alien-Robot relationships. How about replacing them with a nice healthy nuclear North American family? With income derived from providing a non-fossil fuel based energy. And get rid of those robots, we need more diverse ethnic types for comic relief. And tone down all that unrealistic slapstick stuff. In fact, set the whole show in present day, not a thousand years from now. It might offend people living a 1000 light years from here.
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.
Consider the Solitaire program a demonstration of technology; in this case an SVG engine. The engine was not created for the sole purpose of supporting it. I have a whole host of future applications in mind for that. The royal suits happen to be a very good text of intricate vector graphics; though the included cards by David Bellot do not use gradient/filter effects.
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.
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...
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 AGG's superior graphics capabilities for certain rendering constructs but ignores the rest.
I may mention the GPL requirement in the latest version is troublesome, but that is not completely fatal. Perhaps I am wrong and should give it another look. I'd be happy if someone can point to an adequate AGG based SVG rendering engine that comes in under 200K.
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. If you would have given my program a spin you might have noticed my disdain for unnecessary fat. Hence no.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.
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 processing overhead is miniscule (probably 4-10K) since I used MSXML. Even so I am thinking of using tinyxml, which may not be too much of an overhead. As long as you don't start using Schemas and other heavier XML constructs, which many SVG editors don't support anyway.
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.
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.
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.
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.
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:-).
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.
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.
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.
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.
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.
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.
Slashdot Mirror
To combat the rising tide of surgically transplanted organs by alien terrorists what is needed is a... probe ...for an organ they dare not change. Like the prostate area.
I would be loath to put a potentially malware infested software like G-WAN on my machines, so am unable to make a direct comparison. I also don't have a machine that matches the spec published for it. Nevertheless, the G-WAN curves are similar to rani's curves for TPS. Perhaps you could share the performance numbers that you have observed?
As for the rest, it was a weekend effort. What more do you expect?
A while back I had written a minimal HTTP server to figure out I/O completion ports in Windows over a weekend. You can download it from (BSD license): http://arunsagar.com/Code/rani.cpp
Similar throughput specs as the OP's server, and the C++ code can be part of the server itself (great for debugging). Buggy and incomplete, but you can play, fix and extend as you wish.
And I just finished reading Anathem. It's quite gripping and entertaining, far from being awful. It is an impressive effort at stitching together some of the leading philosophical and scientific issues of our time in a work of fiction. It is still a Neal Stephenson book -- meaning there is 3 pages of plodding drivel for every page of sheer brilliance. But he has improved from his Baroque cycle (>10:1 ratio). I think you gave up too early, i.e., the good stuff happens in the second half of the book. It also helps if you are going "WTF?" trying to make sense of the Arban vocabulary and mythos; that means the book is thought provoking and you will probably enjoy it as a result. I would hate to even give a hint as to how it progresses, but it is totally a hard sf book, about as hard as it can get without becoming non-fiction. It could have had more humor like his earlier work, but he probably ratcheted down given the nature of the story. Unlike his earlier books, even the ending doesn't suck, which is saying a lot.
The best way to read this book is to imagine a puzzle's solution is being unfurled right before your eyes. You can guess what it will look like at the end, and may even solve it before the book is over; nevertheless it is the journey, the experience of reading the book, that makes it worthwhile. Or not, if you don't like long 1000 page journeys unless they are all adrenaline pumping every single page.
If you break down accessibility in to 3 essential components : 1. local loop, 2. back-haul, 3. international connectivity, you'll find that India has severe problems with 1&3 and not 2. You can get all the expertise for 2, but there is a de-facto cartel blocking cheap access to #3 and even if you were to solve that problem (through better negotiations or laying your own ocean fibre), I think the worst problem is #1. Even that suffers from a difficult problem: lack of demand. Of the people willing to pay for broadband, most will opt for the Rs.100-250/mo plan for crapband. Very few will see the value in the Rs.1000/2Mb+(uncapped) plan and they will not drive your market in volume. I think this is the reason that Reliance, Tata and Bharti have not expanded their ISP offerings beyond the top tier markets and they basically have no problems with #2 above (or even #1, which is a relatively minor marginal expense).
Unfortunately and very regrettably, I think your venture is doomed, much like Indian Railways' railnet.
Great my ass, aye.
It's not as if they will incur the wrath of Xenu if Bender joins an adventure club.
Personally, I would like to see some more changes. Too many dysfunctional Euro-Alien-Robot relationships. How about replacing them with a nice healthy nuclear North American family? With income derived from providing a non-fossil fuel based energy. And get rid of those robots, we need more diverse ethnic types for comic relief. And tone down all that unrealistic slapstick stuff. In fact, set the whole show in present day, not a thousand years from now. It might offend people living a 1000 light years from here.
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.
Consider the Solitaire program a demonstration of technology; in this case an SVG engine. The engine was not created for the sole purpose of supporting it. I have a whole host of future applications in mind for that. The royal suits happen to be a very good text of intricate vector graphics; though the included cards by David Bellot do not use gradient/filter effects.
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.
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...
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 AGG's superior graphics capabilities for certain rendering constructs but ignores the rest.
I may mention the GPL requirement in the latest version is troublesome, but that is not completely fatal. Perhaps I am wrong and should give it another look. I'd be happy if someone can point to an adequate AGG based SVG rendering engine that comes in under 200K.
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 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 processing overhead is miniscule (probably 4-10K) since I used MSXML. Even so I am thinking of using tinyxml, which may not be too much of an overhead.
As long as you don't start using Schemas and other heavier XML constructs, which many SVG editors don't support anyway.
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.
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.
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.
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.
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
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.
...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.
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.
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.
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.
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.