Currently we scale using the fast algorithm: vcl/source/image/ImplImageTree.cxx:187: rParameters.mrBitmap.Scale(aScaleFactor, aScaleFactor, BmpScaleFlag::Fast); After fixing bug 119020 people thought about improving the quality of the scaled icons. The fix itself is rather easy: change ::Fast to ::Default or ::BestQuality. For OpenGL it will even be done via shaders in HW. Now I know this is almost a bikeshedding bugreport, but still, the icons are cached, so it would just slow down the first start. Maybe TDF will have a tender for my proposal: "[...] implement scaling as a completely asynchronous background job, which can dynamically update any images (which would also be cool to have for document open times with many images of any kind, which need scaling for zoom level, also PDF or SVG)." OTOH we also want to deliver the SVG icon sets, currently independent from the PNG versions.
Do we have some ideas of the actual CPU cost of doing this - is it even measureable ? =) would be good to measure that. Thanks !
We have chosen ::Fast because it is better suited for simplistic icons like breeze and sifr. It has no blurring, just doubling of pixels so it retains the sharpness. But generally I think it is a waste of time discussing and measuring this as SVG icons make this irrelevant.