Qt SVG renderer

[Riccardo Iaconelli]

Il Tuesday 29 July 2008 21:42:42 Matthew Woehlke ha scritto:
> Thiago Macieira wrote:
> > On Tuesday 29 July 2008 18:20:01 Matthew Woehlke wrote:
> >> Rafael Fern�ndez L�pez wrote:
> >>> http://media.ereslibre.es/2008/07/icons/
> >>>
> >>> Here you can find a full list of icons that are misdrawn, and how
> >>> inkscape draws it.
> >>
> >> What's with all the icons that have "junk" behind them? Is that extra
> >> stuff in the svg (that could, and probably should, be deleted), or how
> >> is Qt managing to munge those?
> >
> > That's what I'm most alarmed about. How did that junk appear?
> >
> > Are those things in the SVG files? If they are, it's like Microsoft Word
> > keeping old revisions when you publish a .doc.

Ok, this might eventually be... not old revisions, but maybe more stuff that 
it should when we like take a gradient from another icon or so. 

> I suspect they're really there, but I was/am (ahem) hoping that one of
> the artists that's familiar with the icons will comment. Otherwise I
> will probably try to dig out one of the offending files and take a look.
>
> I remember old versions of the Oxygen cursors had ~6 draft versions in
> the svg as well as the one that was meant to actually be rendered, which
> is why I say I wouldn't be surprised if cruft had been left in the
> svg's.

Nah, that was just me being awesome. ;-)
I did this in the early phase of experimenting, and then was feeling bad in 
deleting the old stuff. We've never done such a thing with icons anyways...

> Probably off to one side or on hidden layers. In fact, since IIRC 
> layers are an inkscape extension, I'd bet on that being the culprit.

We don't use layers almost at all in inkscape, and anyways that kind of usage 
of layers for drawing icons would be pretty strange, if not totally insane.

> In fact, if the problem is hidden layers, then IMO Qt doesn't need to
> fix that; the SVG's need to be fixed (preferably to have the junk
> deleted, which will make them smaller also, but at least moved to where
> it won't render).

hmm.. *if* it's an SVG problem. It might be and it might be not, I know that 
inkscape is often generous and leaves around more data than it should when 
interacting with files, but at this point it seems pretty strange to me.

> Thanks for the info. I don't know the specs very well, but I think as a
> stop-gap, even a crude approximation of blur (i.e. just recognize blur
> and make the right stuff fuzzy) would be a significant improvement.

Definitely. Also consider that Zack already wrote a good blur algorithm, and 
we have this in Plasma, so it shouldn't be much of a problem to get it 
correct immediately.

> I'm not sure about masking, again I don't know the SVG syntax, but as
> for the drawing side, I'd think with the P-D drawing modes that would be
> relatively easy?

That's what I assumed, too.

> IOW, from my perspective the priorities are:
> - fix any egregious issues* (high)
> - *some* form of working blur (high)
> - clipping/masking (med-high)
> - fix any significant issues* (medium)
> - "correct" blur (med-low)
> - support common filters (low)

I agree with most of these items, I'd just swap the lastest two...

Personally, what I'm mostly concerned of is why we are doing this, except that 
for a marketing reason. I don't see what we gain with this approach (or, if 
we do gain something, that's very little) but we risk to introduce a huge 
overhead. And by using raster icons we're free to retouch the PNG even 
further, or use rendering tricks (e.g. rendering to double the size and then 
scale down with imagemagik) to ensure the best look possible.

By the way... to render some non-standard sizes, e.g. 38x38, I'd suggest 
always scaling from the 128x128 icon, that will lead to much better results 
that e.g. scaling it from the 48x48 version, which is what we do now. The 
result should be almost perfect, or anyways good enough...

Bye,
-Riccardo
-- 
GPG key:
3D0F6376
When encrypting, please encrypt also for this subkey:
9EBD7FE1
-----
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화