Re: HiDPI bits ...

[Michael Meeks <michael.meeks@xxxxxxxxxxxxx>]

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