[Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 20 de julho de 2016 20:13:07 PDT Prav wrote:
> Hello, Everyone.
> 
> > That's one reason, but there are two more equally, if not more important:
> > 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
> > applications suffer if they use it.
> 
> Why SVG support of QIcon can not cache rendered result? So re-rendering will
> be as fast as for PNGs. Or you are saying about app startup time?

Startup.

> Also there was idea in this thread earlier that SVG rendering can be done
> much faster ... like in old Opera browser. Why Qt company cann't ask Opera
> to share this part of old Presto engine? They decided to not use Presto
> nowdays so no loses for them.

I can't speak for business decisions. But however faster that engine is, it'll 
still be orders of magnitude slower than PNG.

> > 2) SVG icons designed for higher resolution, with a lot of details, look
> > complex and polluted in lower resolutions. From past experience, icon
> > artists prefer to render the SVG to a lower resolution and retouch them.
> 
> This is a problem. But I do not see many such icons in Material-style. They
> are mostly simple. So I would expect modern styled-apps will not have this
> problem massively.

I don't know what Material is, but whatever it is, I doubt it allows you to 
make that generalised assumption.

> But for people who really want raster images to be aplied ... may be it is
> possible to add some method to QIcon which will store this specially
> rastered QPixmap in icon and will render icon with this pixmap if icon size
> is small. But I am sure most apps will be happy with just SVG rendering.
> This is such a detailed work ... not sure that many apps creators will
> decide this work as a high priority.

As Morten said, Qt does not have a choice: we have to support both SVG and 
raster icons.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center