Re: HiDPI bits ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux