Runtime decision for QSvgRenderer workarounds

Jakob Petsovits jpetso at gmx.at
Tue May 27 15:12:00 BST 2008


On Tuesday, 27. May 2008, Allan Sandfeld Jensen wrote:
> On Tuesday 27 May 2008, Jakob Petsovits wrote:
> > Hi list,
> >
> > as you may or may not know, QSvgRenderer has not yet been considered
> > accurate enough for rendering Oxygen icons on the fly. That has two
> > noticable effects:
>
> Correct me if I am wrong, but wasn't one of reasons we have shipped PNGs
> for this long because the small sizes (16x16) are too ugly if not manually
> cleaned and sharpened after being scaled?

Yes, that's right, and it will stay this way with or without this patch.

> Is this no longer an issue, or do we not care about small icon sizes
> anymore?

This is an issue, and we do care about this. Most icons in Oxygen at least 
(and also in many other popular themes) ship with SVGs for large sizes and 
PNGs for small sizes. And that's exactly the use case that the current 
KIconLoader handles badly, by ignoring SVGs even at large sizes and using 
scaled-up small-size icons instead, which is ugly.

> I always thought SVG icon-sets therefore would use PNGs when available and
> only use SVGs for unavailable sizes.

In theory, yes. With #define KDE_QT_SVG_RENDERER_FIXED, yes.
When that is #undef'd though, SVGs are ignored unless there are only SVGs.

My patch tries to fix that so that a theme must explicitely say
"we want no SVG generation because QSvgRenderer is lame".

But the standard behaviour should be to make use of SVGs imho, because not 
doing so might avoid some icon glitches but will at the same time make most 
iconsets unbearable by using ugly scaled PNGs instead of rendered SVGs.

Did that sound a bit more understandable?
Hoping so, wishes,
  Jakob




More information about the kde-core-devel mailing list