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