Excellent point Luciano! EEEPc is a wonderful example.<span class="EP8xU" style="color: rgb(0, 104, 28);"></span><br><br><div class="gmail_quote">On Dec 19, 2007 4:24 PM, Luciano Montanaro <<a href="mailto:mikelima@gmail.com">
mikelima@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Il Wednesday 19 December 2007 21:33:08 Mauricio Piacentini ha scritto:
<br><div class="Ih2E3d">> Eugene Trounev wrote:<br>> > This is great! I was thinking about compressing all the files into SVGZ<br>> > before, but this is even better! Can we have it added right into the<br>
> > installation process? Would be cool! Is it possible to get it in before<br>> > 4.0?<br>><br>> I do not think we should consider adding anything new at this point,<br>> unless it solves bugs. 4.0 is locked.
<br>><br><br></div>I have no problem with this. It's quite easy to test things still work as<br>intended... but yes, something may go wrong none the less :).<br><div class="Ih2E3d"><br>> The svg optimizer looks like a good idea at the installation phase for
<br>> Linux, but at the same time... let us play devil's advocate here.<br>><br>> Loosing the Inkscape/sodipodi entities gives us a 10% gain on disk, but<br>> possibly makes it more difficult for possible contributors to help us,
<br>> right? I mean: we would be then working with two sets of files: one<br>> would be the "official" SVN art, and the other would be the "stripped"<br>> one installed on-disk. Are the savings really worth it? We would be
<br>> losing layer names, for example, and other stuff that could be useful to<br>> reintegrate contributions into the original source files. In my mind,<br>> compressing to svgz results in MUCH greater savings on disk, with no
<br>> side effects on editability. If we are thinking about saving disk space,<br>> then using svgz in all cases is the way to go, not stripping the svg, imo.<br>><br><br></div>Right. However, another approach may be to offer the editable artwork
<br>somewhere accessible, like <a href="http://kdelook.org" target="_blank">kdelook.org</a>, with good instructions on how to<br>improve and contribute back. While it's true that at the moment the gain is<br>of the 5-10% in size, that's about disk size. if the compressed svg is 100K
<br>in size, the svg library will have to handle 1MB of text, possibly much more.<br>While that's not much for today's desktop, it may be a problem on machines<br>without much RAM.<br><br>So, as if it's worth it... well, I suppose it depends. Right now there are
<br>interesting new targets for KDE, like the eeePC, where filesystem space is at<br>a premium.<br><br>By the way, the current situation is that we have SVG files that are hardly<br>editable... the Chinese landscape in KMahjongg seems heavily hand-optimized
<br>to me. If we had a postprocessor that could do some optimization on editable<br>files, we could have truly "source" SVG files around, and rely on the<br>postprocessor to keep loadingtime etc. reasonable.<br>
<div class="Ih2E3d"><br>> Also, the performance will not increase, right? At least not in any<br>> measurable way, as the bulk of time is spent on rendering the curves,<br>> and blitting to the screen.<br><br></div>
Well, not on my laptop anyway. But it would be good to try this on slower<br>machines. One of the comments that prompted me to try this out was one from<br>Aaron Seigo about qsvg spending much time in css decoding. Essentially, the
<br>first things I did was removing redundant css styles. The sodipodi-stripping<br>stuff came later. If you prefer, I can keep those in -- the style attributes<br>and the space removing already reduce file size quite a bit, and nothing
<br>important for editing is removed.<br><div class="Ih2E3d"><br>> In other words, it is something we should<br>> consider for 4.1, but I do not see a clear benefit in having this (two<br>> sets of SVGs), and I see some possible pitfalls. Maybe I am not seeing
<br>> the whole picture?<br>><br><br></div>Well, it's probably early to tell. I'll keep poking at my little program,<br>let's see how things develop.<br><font color="#888888"><br>Luciano<br></font><div><div>
</div><div class="Wj3C7c">_______________________________________________<br>kde-games-devel mailing list<br><a href="mailto:kde-games-devel@kde.org">kde-games-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kde-games-devel" target="_blank">
https://mail.kde.org/mailman/listinfo/kde-games-devel</a><br></div></div></blockquote></div><br>