HiDPI bits ...

classic Classic list List threaded Threaded
3 messages Options
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

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.

--
[hidden email] <><, GM Collabora Productivity
Hangout: [hidden email], Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view
|

Re: HiDPI bits ...

Hi Michael.

Am 21.01.19 um 14:07 schrieb Michael Meeks:
> For Online, Kendy implemented HiDPI in such a way that the LibreOffice
> code is mostly unaware that the underlying surface has a different DPI.

I was looking a bit into DPI stuff lately myself, because of
https://bugs.documentfoundation.org/show_bug.cgi?id=122131

Qt5 has also some internal, device-independent representation and then an external one.

I'm all for hiding as much DPI handling as possible in the lower layers.

The I have the currently "fun" fact that LO KDE5 backend, which uses Cairo for the actually
rendering, is currently broken with respect to unsing Qt 5.9 (ok) against Qt 5.11 (broken).

> + done with SAL_FORCE_VCLPLUGIN=gen SAL_FORCEDPI=200
Ah - forgot about SAL_FORCEDPI, which doesn't work for our mostly native menus.

> 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 =)

Now I think I've read the mail more then two times, but what is the difference you're comparing here?

> Anyhow - further thoughts ?

I'm a bit confused. What are you proposing / asking?

> ATB,

Jan-Marek
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Re: HiDPI bits ...

Hi Jan-Marek,

On 21/01/2019 16:29, Jan-Marek Glogowski wrote:
> I was looking a bit into DPI stuff lately myself, because of
> https://bugs.documentfoundation.org/show_bug.cgi?id=122131

        Great =)

> Qt5 has also some internal, device-independent representation and
> then an external one.
>
> I'm all for hiding as much DPI handling as possible in the lower
> layers.

        Good good; that's basically the proposal.

> The I have the currently "fun" fact that LO KDE5 backend, which uses
> Cairo for the actually rendering, is currently broken with respect to
> unsing Qt 5.9 (ok) against Qt 5.11 (broken).

        Ah - so, adapting the new HiDPI thing to cairo is trivial - we just
tweak the transform we render through at a low level (already there in
the headless / cairo backend).

>> + done with SAL_FORCE_VCLPLUGIN=gen SAL_FORCEDPI=200
>
> Ah - forgot about SAL_FORCEDPI, which doesn't work for our mostly
> native menus.

        Right SAL_FORCEDPI uses this:

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

        API and approach, which is then used in tons of explicit code to try to
scale images and tweak font sizes.

>> And instead using the approach of:
>>
>> COMPHELPER_DLLPUBLIC double getDPIScale();

        Which is an API that we use in about ~4 call-sites:

git grep -5 getDPIScale

        To get a much better result. FWIW - Calc really needs to know about
underlying device pixels to have a chance of working well.

> Now I think I've read the mail more then two times, but what is the
> difference you're comparing here?

        I'm saying we should go with the ~industry standard of adding a
transform at the lowest level of our drawing and leave everything the
same except where really necessary - rather than trying to instrument
all the code.

        A quick:

git grep -5 GetDPIScaleFactor

        And seeing quite how incomplete the result is ;-) gives you a quick
taste for the difference between the two approaches.

> I'm a bit confused. What are you proposing / asking?

        So - I'm suggesting we:

        * kill GetDPIScaleFactor - making it all 1.0
        * remove all code associated with these tweakings.

        * implement a VCL based equivalent to getDPIScale
        * connect that to platform HiDPI libraries as well
          as the existing comphelper::getDPIScale for LO Kit.

        => finished  ...

        Hopefully that makes sense; Noel seemed interested =)

        HTH,

                Michael.

--
[hidden email] <><, GM Collabora Productivity
Hangout: [hidden email], Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice