HiDPI bits ...

Hi there,

        I'd like to give a quick update on HiDPI as I see Noel (sensibly)
trying to cut out some of the complexity that comes from the existing
(hopefully old) way of doing this:

        https://gerrit.libreoffice.org/#/c/66582/1

        For Online, Kendy implemented HiDPI in such a way that the LibreOffice
code is mostly unaware that the underlying surface has a different DPI.
This is rather similar to how Mac, gtk+, etc. do this. Why do they do it
this way ? it ensures that all of the layout decisions and legacy
artwork are automatically scaled and rendered.

        The nice thing about doing this is that we can then scale images as we
actually render which gives good quality - or ideally re-render SVG
images at high fidelity - while retaining the layout and positioning of
elements in all our dialogs. So some examples:

https://people.collabora.com/~mmeeks/hidpi/lok-hidpi.png
        + DPI scaling done on the cairo output device with some
          smarts adapting higher up.

https://people.collabora.com/~mmeeks/hidpi/scale-hidpi.png
        + DPI scaling attempted per item
        + notice Line Arrangement, Line, Padding columns got
          more cramped for no obvious reason.
        + I've seen far worse examples but can't find them now =)
        + notice missing icons: no idea why, not read the code
        + done with SAL_FORCE_VCLPLUGIN=gen SAL_FORCEDPI=200

vs. original:
https://people.collabora.com/~mmeeks/hidpi/non-hidpi.png
        + but gtk+ themed.

        Of course - the native / welded gtk+ widgets here add another dimension
- since they have their own built-in DPI scaling: hopefully matching
this to a model whereby we have a low-level scale-factor on the
underlying rendering (Cairo) surface as per LOK works well.

        One of the problems with instrumenting all of the code for HiDPI is
that this creates work all over the code - cf. Noel's patch above
removing some of it so eg.

https://people.collabora.com/~mmeeks/hidpi/scale-hyper-hidpi.png

        is clearly missing some custom scaling logic for the wizard images vs.

https://people.collabora.com/~mmeeks/hidpi/lok-hyper-hidpi.png

        Where no custom scaling is/was needed.

        Another interesting thing here is that the lok approach retains the
same layout goodness independent of DPI - such that we can render the
same dialogs at different DPIs depending on which client is asking for
them to be rendered: vital for Online.

        So ... =) anyhow.

        The purpose of this mail is to start (or perhaps conclude?) a
discussion on how best to do HiDPI in LibreOffice. Currently we try to
do it two ways.

        I'd really prefer to do it one way (+ welding) - and to move away from
adding shed loads of custom code all over the place that does things like:

BitmapEx aBitmap(RID_SVXBMP_NEWDOC);
aBitmap.Scale(GetDPIScaleFactor(),GetDPIScaleFactor(),BmpScaleFlag::BestQuality
);

        And do all of this under the hood for the most part. That would mean
removing:

include/vcl/outdev.hxx:    float GetDPIScaleFactor() const

        And instead using the approach of:

COMPHELPER_DLLPUBLIC double getDPIScale();

        Certainly having two of these in play where only one can be used at
once is confusing =)

        My hope is that we can get a nice icon quality win on Mac rather
trivially by teaching image rendering about Mac's underlying DPI magic;
as we've done for LOK:

void Image::Draw(OutputDevice* pOutDev, const Point& rPos,
DrawImageFlags nStyle, const Size* pSize)
{
...
    Size aOutSize = pSize ? *pSize :
pOutDev->PixelToLogic(mpImplData->getSizePixel());

    BitmapEx aRenderBmp = mpImplData->getBitmapExForHiDPI(!!(nStyle &
DrawImageFlags::Disable));

        Where we render the bitmap into a given size in 100% co-ordinates, but
fetching the actual underlying bitmap scales it to provide more
information for the lower levels.

        I guess there is a trivial win for Mac here too by instrumented
gitBitmapExForHiDPI to know about Mac's underlying surface DPI.

        Beyond that - of course, Windows - we'll need to also poke at the DPI
pieces - it seems they are doing something rather similar there cf. GDI
scaling:

https://blogs.windows.com/buildingapps/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/

        Which we can presumably enable and get some rapid wins here too with
very little code, which keeps our look consistent across DPI levels.

        Anyhow - further thoughts ?

        ATB,

                Michael.

-- 
michael.meeks@collabora.com <><, GM Collabora Productivity
Hangout: mejmeeks@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe