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 &lt;<a href="mailto:mikelima@gmail.com">
mikelima@gmail.com</a>&gt; 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">&gt; Eugene Trounev wrote:<br>&gt; &gt; This is great! I was thinking about compressing all the files into SVGZ<br>&gt; &gt; before, but this is even better! Can we have it added right into the<br>
&gt; &gt; installation process? Would be cool! Is it possible to get it in before<br>&gt; &gt; 4.0?<br>&gt;<br>&gt; I do not think we should consider adding anything new at this point,<br>&gt; unless it solves bugs. 4.0 is locked.
<br>&gt;<br><br></div>I have no problem with this. It&#39;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>&gt; The svg optimizer looks like a good idea at the installation phase for
<br>&gt; Linux, but at the same time... let us play devil&#39;s advocate here.<br>&gt;<br>&gt; Loosing the Inkscape/sodipodi entities gives us a 10% gain on disk, but<br>&gt; possibly makes it more difficult for possible contributors to help us,
<br>&gt; right? I mean: we would be then working with two sets of files: one<br>&gt; would be the &quot;official&quot; SVN art, and the other would be the &quot;stripped&quot;<br>&gt; one installed on-disk. Are the savings really worth it? We would be
<br>&gt; losing layer names, for example, and other stuff that could be useful to<br>&gt; reintegrate contributions into the original source files. In my mind,<br>&gt; compressing to svgz results in MUCH greater savings on disk, with no
<br>&gt; side effects on editability. If we are thinking about saving disk space,<br>&gt; then using svgz in all cases is the way to go, not stripping the svg, imo.<br>&gt;<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&#39;s true that at the moment the gain is<br>of the 5-10% in size, that&#39;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&#39;s not much for today&#39;s desktop, it may be a problem on machines<br>without much RAM.<br><br>So, as if it&#39;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 &quot;source&quot; SVG files around, and rely on the<br>postprocessor to keep loadingtime etc. reasonable.<br>
<div class="Ih2E3d"><br>&gt; Also, the performance will not increase, right? At least not in any<br>&gt; measurable way, as the bulk of time is spent on rendering the curves,<br>&gt; 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>&gt; In other words, it is something we should<br>&gt; consider for 4.1, but I do not see a clear benefit in having this (two<br>&gt; sets of SVGs), and I see some possible pitfalls. Maybe I am not seeing
<br>&gt; the whole picture?<br>&gt;<br><br></div>Well, it&#39;s probably early to tell. I&#39;ll keep poking at my little program,<br>let&#39;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>