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/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
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.
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:
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?
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.
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 =)