[Kde-games-devel] A simple svg optimizer

[Eugene Trounev]

Excellent point Luciano! EEEPc is a wonderful example.

On Dec 19, 2007 4:24 PM, Luciano Montanaro <mikelima at gmail.com> wrote:

> 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
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20071219/8ebb6325/attachment-0001.html