[Kde-games-devel] A simple svg optimizer

[Luciano Montanaro]

Il Wednesday 19 December 2007 21:33:08 Mauricio Piacentini ha scritto:
> Eugene Trounev wrote:
> > This is great! I was thinking about compressing all the files into SVGZ
> > before, but this is even better! Can we have it added right into the
> > installation process? Would be cool! Is it possible to get it in before
> > 4.0?
>
> I do not think we should consider adding anything new at this point,
> unless it solves bugs. 4.0 is locked.
>

I have no problem with this. It's quite easy to test things still work as 
intended... but yes, something may go wrong none the less :). 

> The svg optimizer looks like a good idea at the installation phase for
> Linux, but at the same time... let us play devil's advocate here.
>
> Loosing the Inkscape/sodipodi entities gives us a 10% gain on disk, but
> possibly makes it more difficult for possible contributors to help us,
> right? I mean: we would be then working with two sets of files: one
> would be the "official" SVN art, and the other would be the "stripped"
> one installed on-disk. Are the savings really worth it? We would be
> losing layer names, for example, and other stuff that could be useful to
> reintegrate contributions into the original source files. In my mind,
> compressing to svgz results in MUCH greater savings on disk, with no
> side effects on editability. If we are thinking about saving disk space,
> then using svgz in all cases is the way to go, not stripping the svg, imo.
>

Right. However, another approach may be to offer the editable artwork 
somewhere accessible, like kdelook.org, with good instructions on how to 
improve and contribute back. While it's true that at the moment the gain is 
of the 5-10% in size, that's about disk size. if the compressed svg is 100K 
in size, the svg library will have to handle 1MB of text, possibly much more. 
While that's not much for today's desktop, it may be a problem on machines 
without much RAM.

So, as if it's worth it... well, I suppose it depends. Right now there are 
interesting new targets for KDE, like the eeePC, where filesystem space is at 
a premium.

By the way, the current situation is that we have SVG files that are hardly 
editable... the Chinese landscape in KMahjongg seems heavily hand-optimized 
to me. If we had a postprocessor that could do some optimization on editable 
files, we could have truly "source" SVG files around, and rely on the 
postprocessor to keep loadingtime etc. reasonable. 

> Also, the performance will not increase, right? At least not in any
> measurable way, as the bulk of time is spent on rendering the curves,
> and blitting to the screen. 

Well, not on my laptop anyway. But it would be good to try this on slower 
machines. One of the comments that prompted me to try this out was one from 
Aaron Seigo about qsvg spending much time in css decoding. Essentially, the 
first things I did was removing redundant css styles. The sodipodi-stripping 
stuff came later. If you prefer, I can keep those in -- the style attributes 
and the space removing already reduce file size quite a bit, and nothing 
important for editing is removed.

> In other words, it is something we should 
> consider for 4.1, but I do not see a clear benefit in having this (two
> sets of SVGs), and I see some possible pitfalls. Maybe I am not seeing
> the whole picture?
>

Well, it's probably early to tell. I'll keep poking at my little program, 
let's see how things develop.

Luciano