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.

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